I gave a talk Wednesday at the Silicon Valley Google Technology Users’ Group on using Quercus in the App Engine. One of the examples I gave was using the low-level data API from PHP and scheduling PHP “tasks” using Task Queues. I’ll walk through the source of that demo here to give you an idea of how Quercus makes it easy to mesh a Java platform with PHP code. At the end, I’ll also give you an idea of what the next steps would be to take this demo and use the techniques in a real application or framework.
Read the rest of this entry »

For the 4.0.4 release (in about two weeks), we’re looking good for passing the Servlet 3.0 TCK. (A Resin snapshot has passed it internally, but we still haven’t cleaned up our own regressions to match.) Alex Rojkov has been our lead on getting the Servlet 3.0 TCK passed, and deserves congratulations for getting the details done for the spec.

The Servlet 3.0 spec along with the CDI (Java Injection) are the biggest and most important pieces in the web-profile from our perspective.

Since unit testing and test-driven development have become accepted as the basis for solid programming practices, we’ve had several requests to provide a lightweight Resin environment specifically tailored to test environments. As our first cut, we’ve created a ResinBeanContainer class, usable outside of Resin, but providing a Resin environment.

The ResinBeanConstainer provides the same environment as a Resin web-app, but without the servlets, HTTP or requests. It provides CDI injection, EJB lite support, database and JPA configuration.

Read the rest of this entry »

We’ve been doing a lot of work on our Resin administration application over the last few releases, adding features like statistic graphs, postmortem reports, and REST. The framework we’re building for these features is also quite extensible and easy to use. One of the in-house extensions we developed combines the REST and graph features so that you can export and embed user-defined graphs. We’ve added this extension to the main application for the upcoming 4.0.4 release so it’s available without any coding. In this blog post, I’ll show you how to embed Resin statistics graphs in your own monitoring tools, how the underlying graph API works, and give some tips on how to write your own similar extensions.

Read the rest of this entry »

Since the JavaEE 6 Web Profile is our main focus for the next few months, I’m going through the JavaEE resource and environment configuration and injection, including the new JavaEE 6 JNDI system. In many cases, though, using CanDI as a registration blackboard is a cleaner, simpler and more type-safe system than using JNDI. Since we believe spending the effort on clean code pays off, the new type-safe capabilities are worth a look.

For example, JavaEE has an <env-entry> tag, which configures literals like Strings and integers. We can replace those with a as follows, and inject a servlet with our configured values:

MyServlet injecting a config var

The configuration using CanDI in the resin-web.xml looks like the following:

resin-web.xml configuring the var

<web-app xmlns="http://caucho.com/ns/resin"
    xmlns:lang="urn:java:java.lang"
    xmlns:ee="urn:java:ee">

  <lang:String>
    <new>my-value</new>
    <ee:Named>my-var</ee:Named>
  </lang:String>

</web-app>

The String is instantiated with <lang:String> with a <new> tag for the constructor. The xmlns:lang tells CanDI the package for java.lang.

The old <env-entry> still works (and the old @Resource works too, but you should start migrating to @Inject). For reference, the env-entry looks like the following:

resin-web.xml configuring the var

<web-app xmlns="http://caucho.com/ns/resin">

  <env-entry>
    <env-entry-name>my-var</env-entry-name>
    <env-entry-type>java.lang.String</env-entry-type>
    <env-entry-value>my-value</env-entry-value>
  </env-entry>

</web-app>

Most of the WebSocket discussion I’ve read has been highly technical: people who love protocols discussing how to upgrade HTTP to a fully-interactive messaging system. But the technical discussion may be obscuring how potentially transformative WebSockets might be. While I never understood the Web 2.0 hype, WebSockets has the potential to be a legitimate Web 3.0 technology.

So here’s my attempt to explain why WebSockets matters in a non-technical way: the 1970’s game of Pong. The clearest example I’ve come up with so far is playing the game of “Pong” on the browser. Plain browser JavaScript driving a fully-interactive Pong game where one player is in California and another in New York. 30 years after Pong was invented, browsers can’t really play it effectively.

In one sense, that capability isn’t new: online interactive games like World-of-Warcraft are far beyond a simple game of pong. Yet, browsers are still limited to HTTP request response, and hacks like AJAX and Comet. It’s like browsers are still using decades-old technology. Now, I’m not quite suggesting turning the browser into a universal game engine, but the current browsers are still crippled by the inadequate request-response client/server model of HTTP. It’s past time to break those limitations.

WebSockets essentially does three things: it improves interactivity by acting on messages instantly - not waiting for a poll, it elevates clients as fully capable of responding to events - clients become actors, and it improves responsiveness by eliminating wasteful housekeeping bandwidth.

To make the game of Pong work, both the browsers and the servers need to upgrade to handle WebSockets. On the server side, Resin provides a Java API to handle messages from clients as soon as they’re available, and forward or process the messages to other clients. The Pong application on the Resin server would act like the referee, handling the ball bounces, and keeping score.

When the California Pong player moves the Pong paddle up, the browser needs to send a message to the Resin server, updating the referee and the game physics. Resin will then process the request, update the ball motion, and send any game updates to the California and New York players. The messages need to happen as quickly as possible so people can immerse themselves in the game. This isn’t play-by-mail chess.

Server and client applications could become more critical and interesting than with HTTP apps, because the demand for each user is greater. Instead of simple GET requests every few seconds returning formatted text pages, each micro-request is a tiny action message telling another actor to do something: move a paddle, bounce a ball, update a score. The web becomes active: not semi-passive as it is today.

Today, the engineers who love the plumbing at the base of the web see the possibility and excitement that WebSocket may bring to the web. And now we’re beginning to see clients like Chrome and servers like Resin bringing the new capabilities to life. The best part is when creative engineers take WebSockets and write the messaging and application code to show the non-engineering world what can be created with a few new low-level technical powers.

Joe Armstrong has a good argument for websockets as the next phase of web development at armstrong: Comet is dead long live websockets:

I think this means the death of the following technologies:

• comet
• long-poll
• AJAX
• keep-alive sockets

All the above are merely hacks, inadequate ways of programming round the central problem that web-browsers could not simply open a socket and do asynchronous I/O like any other regular application.

His example uses Erlang, but the same idea applies with Resin’s WebSocket support

Apache Chainsaw is a popular graphical logging tool for Java. Even though it’s based on Log4j and Resin’s logging uses java.util.logging, you can use Chainsaw to analyze Resin’s logs in real time. In this blog, I’ll show you how to connect Resin with Chainsaw using a technique that can be extended to other Log4j-based analysis tools.

Read the rest of this entry »

Like other lightweight servlet containers and Java EE application servers, Resin’s deployment is file-system based. In order to deploy an application, all you need to do is copy your file to the Resin deployment directory. As you might also know, Resin has supported hot deployment for quite a while, which is a great feature for agile development that often results in frequent incremental deployments.

This deployment model is very simple, effective and popular. However, file-system based deployment has a few weaknesses that can arise in environments with very stringent availability and reliability requirements. It is very difficult to do deployment in a clustered environment because the same file must be deployed simultaneously to all servers in the cluster. Often this can result in some down-time that must be announced beforehand. No back-up facility is provided by the file system, so you must often save a backup copy of the old deployment somewhere yourself. File system based deployment also makes it very difficult to use the same server environment for different stages of development such as QA, user acceptance testing and production without following complicated deployment procedures.

The remote deployment model introduced in Resin 4.0 goes a long way in solving these particular problems by supporting clustered, versioned and staged deployment. This blog entry discusses these features in detail.
Read the rest of this entry »

WebSocket support is a new feature we added in Resin 4.0.2 that I’m very excited about. The WebSocket API is a new HTML 5 capability giving browsers full bi-directional asynchronous messaging capability. Like an instant messaging client, either the browser or the server can send a message at any time.

Unlike Comet and long-polling, WebSockets uses a single persistent TCP connection, giving much better response times. If all works as planned, browsers will be able to run truly interactive applications.

I’ve added a rough draft of a WebSocket tutorial in Resin (running on the caucho.com server.) To run it, you’ll need to download the nightly Chrome build.