Blog

The guys at
Atomikos, creators of the excellent JTA/XA transaction manager have decided to go open source.
We first got to know Atomikos when we integrated it with Jetty5, and we’ve also done the integration with Jetty6. We’ll be working closely together again at Webtide to provide a tightly integrated transaction manager for the Hightide open source project.
The guys at Atomikos have always been extremely helpful and knowledgeable, so we say “Welcome to open source!” and wish them the best for the future.

Jetty Jspc Maven Plugin
I’ve added a new maven2 plugin that does jsp pre-compilation. Just like the Jetty Maven Plugin, the new plugin detects whether jsp2.0 or jsp2.1 is required at runtime and generates the correct classes accordingly.
All you need to do is to configure the plugin in your pom.xml and you can have your jsps compiled and your web.xml file updated ready for going into production without having to resort to ant build files.
I have a few ideas for improvements, so I’m interested in communicating with users who have particular requirements, so please check it out and send an email to jetty-discuss@sourceforge.net with your feedback.
The plugin is available from svn head of jetty at the moment, but we’ll push a 6.1-SNAPSHOT to the maven repos soon.

Greg Wilkins, the lead developer of Jetty and CEO of
Webtide, will be speaking at this years AJAXWorld Conference. Greg’s presentation is about the challenges of scalably serving Ajax Comet from Java Servlets. The various asynchronous servlet extensions are evaluated and several case studies examined.

Webtide has joined the Open Ajax Alliance.
The chief goal of the alliance is to accelerate customer success with Ajax by promoting a customer’s ability to mix and match solutions from Ajax technology providers and by helping to drive the future of the Ajax ecosystem. Among the organizations who have joined so far: IBM, Sun, Yahoo, Google, Mozilla, Opera, Adobe, Oracle, SAP, BEA, TIBCO, SoftwareAG, Eclipse Foundation, Intel, Novell, RedHat, Borland, Dojo Foundation, Zimbra (leaders beyind the Kabuki toolkit), Zend (the PHP company), Backbase, Jackbe, Icesoft, Laszlo, and Nexaweb.

Webtides involvement in the alliance reflects their focus on open standards and desire to be bring standardization and interoperability to the java servlet extensions currently used to scalably serve Ajax webapplications.

Until now, Jetty has not provided Java Server Pages Standard Tag Library nor Java Server Faces support with the container. Webapps wishing to use either of these facilities have had to explicitly include the necessary jars in their webapps.

With the rc1 version of Jetty 6, the JSTL1.0 and JSTL1.1 libraries will be automatically on the classpath for webapps using JSP2.1. This means webapp developers will be able to simply use these tags in their jsps. These JSTL goodies will also be available for Jetty maven plugin users too.

Apart from simplified development, webapps will now be more transportable between web containers supporting servlet2.5 (although why would you ever want to move away from Jetty 🙂 ). Also, it will facilitate moving the webapp to a full-blown JavaEE container should it become necessary.

Also from rc1, we have put the wiring in place to support container-wide availability of Java Server Faces implementations such as MyFaces or the JSF RI. We will not be distributing a JSF impl with Jetty, but you will be able to install your favourite into Jetty’s lib/ext directory (which is the location for jars to be shared between all deployed webapps) and follow the simple instructions I’ve put on the wiki:

My Faces instructions or JSF RI instructions

Keep checking the download page, as rc1 is on it’s way.

I’ve been looking at Glassfish quite a bit lately, and liking what I see.
In particular, I’ve been looking closely at the JSP 2.1 implementation. It appears to be robust and well-tested.

My interest was prompted by the number of bug reports we were getting on the Jetty mailing lists about the JSP 2.1 implementation we were using, which was Jasper from Apache. For whatever reason, there seems to be little activity on this particular project.

Glassfish, however, has an active community of developers who were welcoming of my initial enquiries about using it in Jetty and who have been very open to collaboration.

It’s worth noting that Glassfish’s jsp implementation is based on that from Apache, and that some of the key developers of previous Apache Jasper versions are now working mainly on Glassfish.

I was able to relatively quickly get a build of Jetty going using Glassfish’s Jasper. Initial testing has been very positive, so much so that we now use it exclusively as Jetty’s JSP 2.1 implementation.

So far, this is available only in SVN head (checkout revision 782), however, we plan to do an rc1 release in the next few days, so stay tuned.

Thanks to Jan Luehe from Glassfish for all the help with the integration, who I believe has blogged
about the integration too.

Cometd is a scalable HTTP-based event routing bus that uses a push technology pattern known as Comet. The term ‘Comet’ was coined by Alex Russell in his post ‘Comet: Low Latency Data for the Browser‘. Cometd consists of a protocol spec called Bayeux, javacript libraries (dojo toolkit), and an event server.
Jetty now has just an implementation of the cometd event server that
uses the Continuation mechanism for asynchronous servlets.
Jetty already has comet implementations for DWR and activemq, but both of these use custom protocols which can lead to interoperability problems that cometd intends to solve.
Because browsers commonly permit only two connections to each server, it is not possible for a web page to use more than one Ajax library that is using comet techniques. The intent of cometd is to define a common protocol that can be shared between libraries and thus
encourage interoperability.
Cometd provides a two multi-channel communications paradigm that allows asynchronous message delivery from server to client as well as client to server. The multi-channel nature of the protocol, will eventually allow a single comet connections to be shared between multiple Ajax toolkits
Jetty has implemented the server side of this protocol, which will allow it to be used with whatever client side implementations emerge (currently only dojo, but I plan to port activemq once it is stable). However to achieve true
interoperability, we will need to develop standardized APIs on both the client and server side. Having standard protocol is a start on this, as it defines the capabilities that will need to be expressed in the APIs

I have reconsidered the API for asynchronous servlets that I proposed in my recent blog – it is not good!. It makes some of the same mistakes as weblogic and tomcat have made with their asynchronous extensions.
So let’s have a brief review of all the available and
proposed solutions.

BEA WebLogic
BEA added AbstractAsyncServlet in WebLogic 9.2 to support threadless waiting for events (be they Ajax Comet events or otherwise eg. an available JDBC connection from a pool). Their API separates the handling of a request and the production of a response into doRequest and doResponse methods. A call to the a notify method or a timeout triggers the invocation of the doResponse call.

This API can certainly be used to handle most of the important use-cases that I have previously discussed, but it suffers from several major flaws:

It’s not really a servlet – The user cannot implement doGet or service methods to generate content so there is limited benefit from tools or programmer familiarity. Furthermore, the javadoc states an AbstractAsyncServlet “cannot be used as the target of request dispatching includes or forwards... Servlet filters which get applied before AbstractAsyncServlets, will not be able to take advantage of post processing of the response.“.es
So an AbstractAsyncServlet cannot be used like a servlet and the URLs that it served will not be able to be re-used (eg. in portlets) and it cannot live behind common filters that may apply aspects (eg security, authentication, compression) . It is a cuckoo in a nest of servlets, only pretending to be a servlet and breaking all the other eggs in the process.

There can only be one. There are many reasons that a wait may be required while handling a request and all are candidates for asynchronous waiting. But as this solution is tied to a single Servlet, either it will have to implement all the waiting concerns or there can only be one efficient wait. For example, it would be unreasonable for a single servlet to implement async waits for a remote authentication server and the arrival of a JMS message and for an available JDBC connection from a limited pool.

It is not portable and servlets that implement this API will fail on containers that do not support it.

I believe AbstractAsyncServlet is a good solution for a particular async use-case, but it is not a candidate as a general approach.

Tomcat 6.x
After my initial blogging on this issue, the tomcat developers added CometProcessor and CometServlet (unfortunately without engaging in an open discussion as I had encouraged). It is essentially the same solution as BEAs, but with a few extras, a few gotchas and the same major issues.

It is still a special type of servlet and the begin and end methods take the
place of BEAs doRequest and notify calls. Asynchronous code directly calls the response object until it a call to end indicates the end of the handling of the request.

The badly named CometProcessor (Comet is only one use-case for async servlets) does support asynchronous IO, but I’ve argued there is little need for this and it would be better to get the container to do IO if there was.

The start method does execute in the context of the Filters mapped to the servlet/URL. However, there is no support for the asynchronous code itself to operate within the context of the filter chain. Thus any non-trivial filters that are unaware of the tomcat mechanism are unlikely to work. Any authentication information or other actions taken by filters will not apply to the code that generates the response. So like the BEA solution it is not a servlet except by name and would not be able to be the used with arbitrary dispatches or generic filters.
There still can only be one and multiple asynchronous aspects may not be combined with this API.

The implementation makes a naive attempt at portability
and will call the begin and end methods in a container that does not support the mechanism. But if the implementation of begin schedules asynchornous writers to the response object (as it should), then this breaks the servlet contract and simply will not work as the response will be committed long before any asynchronous handling.

ServletCoordinator
My proposed ServletCoordinator suffers from many of these same issues. It does meet one of my main concerns in that responses are generated by normal servlets code using normal techniques and within the scope of the applicable filter chain. But there still can only be one and there is no support for multiple asynchronous aspects. It avoids being an ugly ducking servlet, but only by not being called a servlet. It is still a new non portable mechanism that is unlikely to work with arbitrary dispatchers
It’s not a cuckoo, it’s a dodo!

Jetty 6 Continuations
The Jetty 6 Continuation mechanism is not an extension to the Servlet API. Instead it as a suspend/resume mechanism that operates within the context of a Servlet container to allow threadless waiting and reaction to asynchronous events by retrying requests.

Continuations well address the concerns I have raised above:

• Request handling and response generation is done within normal servlets and always within the scope of the applicable filter chain. Common tools and frameworks can be used without modification.
• If RuntimeExceptions are propogated and the stateless nature of HTTP respected, then there is a reasonable expectation that arbitrary filters and dispatchers may be applied.
• There can be multiple asynchronous concerns applied as each may independently use a continuation. For example, it is possible to apply the ThrottlingFilter in front of the activemqAjaxServlet and while both use Continuations, neither will interfer with the other.
• It is truely portable and if run within a container that does not support Continuations, will fall back to threadful waiting.

While some (including myself) are a little perturbed by the way RuntimeExceptions are used by Continuations, I argue that should be seen as an implementation detail and that the semantics of the API are correct for the purpose. There are already byte-code manipulating continuation solutions available and rumours of future JVM support, so the implementation can be improved.

Thus I have not yet seen a better API than continuations for the majority of the asynchronous use-cases within the
servlet model. More over, I believe that the async APIs of BEA and tomcat can be trivially implemented in a container supporting continuations, but that the inverse is not true.

Mort Bay has been a successful small open source services company for over 10 years. But the business of open source is changing and is there is more demand for support and services from larger organizations. Thus Mort Bay has partnered with
Exist to form Webtide and joined a family of open source companies based around Simulalabs that includes Logicblaze (activemq/servicemix) and Mergere (maven).

We will continue to provide the same training, development and support services, but with Webtide we will be able to scale our offerrings to a higher level of professionalism.

If you are at OScon Portland, then please come to our briefing and get-together at the Red Lion this Friday evening.

Webtide is an new services company that provides training, development and support for web 2.0 applications, with particular focus on the server side of scalable Ajax Comet solutions. Webtide can train or mentor your engineers in these emerging technologies, provide open outsourced development and give you the assurance of 24×7 support.

Webtide is a joint venture between Mort Bay Consulting, the creator of the highly regarded Jetty open source Java web container, and Exist, a premier software development company supporting open source technology. Webtide will be formally launched during the O~@~YReilly Open Source Convention in Poortland, Oregon on July 24-28, 2006.

To learn more about Webtide and its products please visit the Webtide booth (Booth 723) at the OSCon Exhibit Area. There will also be a Webtide Product Briefing on July 27, 2006, 6:15-7:15pm at the Broadway Room, 6th Flr of the Red Lion Hotel, 1021 NE Grand Ave., Portland, OR. The first 30 registered participants will get a chance to win an HP iPAQ running Jetty. For more info, please email mailto:training@webtide.com or visit http://www.webtide.com

Greg Wilkins and Jan Bartel, the lead developers of Jetty, recently launched Webtide at the O’Reilly’s Open Source Convention 2006 held at the Oregon Convention Center. Webtide, a company specializing in Web 2.0 and AJAX technologies, is a partnership between Mortbay – the creator of Jetty, the highly regarded open source Java web container and Exist – a premier software development company supporting open source technology.

The launch was followed by an introduction to Webtide’s latest product called Hightide, a versioned distribution of Jetty that is optimized for Ajax. The event was held at the Red Lion Hotel in Portland, Oregon where thumb drives containing Hightide were distributed to guests. One lucky guest