The way that you start and stop Resin and the watchdog have changed a bit in the 4.0 branch. I realized as I was writing the Resin Refcard that there are probably a few options and concepts that many users don’t fully understand. In this post, I review the Resin watchdog architecture and show the syntax while highlighting recent changes. I’ll also describe some of the thoughts we have for the future of the watchdog and solicit your ideas and input.

Read the rest of this entry »

Over the last couple of weeks, I’ve been getting oriented with Jigsaw, seeing the progress they’re making and wondering how this work will affect our Java EE world. Though I still have a few questions remaining, I’ve found the high-level concepts to be very impressive. Moreover, the language-level approach that Jigsaw is taking is well-suited to integration with Java CDI. As you may know, Caucho is a major supporter of the Java CDI spec and we’re working on our own implementation, called CanDI. In this blog post, I’ll talk about the cool parts of Jigsaw and sketch a proposal for how Jigsaw and CDI might work together in the future.

Read the rest of this entry »

We at Caucho are very excited in working steadily towards getting Resin certified on the recently finalized Java EE 6 Web Profile. Along with GlassFish and JBoss, we are aiming to provide one of the earliest solid implementations for Java EE 6. In fact, Resin is the only major application server focused solely on delivering a very lightweight implementation targeting just the Web Profile.

This blog entry briefly discusses the Java EE 6 Web Profile, what it offers and how it fits with the lightweight development philosophy of Resin as well as the details of our implementation including Resin extensions to the Java EE 6 Web Profile.

Read the rest of this entry »

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