The Jetty 6.1.0 release is now available via http://jetty.mortbay.org. It represents both a stabilization of the features already released in 6.0.x, plus a raft of new features. For a full description of
Jetty 6.1, see http://docs.codehaus.org/display/JETTY/.

Stabilization

The core protocol engine of Jetty 6 has been further optimized and refined in 6.1, plus it has been extended to support asynchronous SSL and a future HTTP client API. Compliance testing and exposure on live deployments has allowed many minor and several major issues to be exposed and fixed.

Deployers

Web Application Static Deployer

The WebApp Deployer is for static deployment standard WAR files and webapps with little or no Jetty specific customization.

See

http://docs.codehaus.org/display/JETTY/WebAppDeployer

Context Hot Deployer

The ContextDeployer may be used to (hot)deploy an arbitrary Context or Web Application with Jetty specific configuration. The ContextDeployer will scan the configuration directory for xml descriptors that define contexts. Any context descriptors found are used to configure and deploy a context and then the descriptor is monitored for changes to redeploy or undeploy the context.
Arbitrary contexts may be configured deployed including simple static contexts and standard webapplications. The web.xml of a war file may be extended or replaced and additional configuration applied, thus allowing configuration to be customized during deployment without modification to the WAR file itself.

See:
http://docs.codehaus.org/display/JETTY/ContextDeployer

Cometd

Jetty 6.1 includes a servlet implementation of the bayuex protocol of http://cometd.com from the dojo foundation.

Cometd is a message bus for Ajax web applications that allows multi channel messaging between client and server – and more importantly – between server and client. The paradigm is publish/subscribe to named channels.

The Jetty implementation uses continuations and will thus scale to many connected clients. It also supports declarative filters for security and validation of channel content.

See
http://docs.codehaus.org/display/JETTY/Cometd

Servlet Tester

The jetty infrastructure can be use to test servlets with an embedded server using the ServletTester and HttpTester classes.
The embedded server uses a special local connector, and thus avoids the need to open sockets in order to test the servlet and is thus ideal for unit testing:

ServletTester tester=new ServletTester();
tester.setContextPath("/context");
tester.addServlet(HelloServlet.class, "/hello/*");
tester.start();
HttpTester request = new HttpTester();
HttpTester response = new HttpTester();
request.setMethod("GET");
request.setURI("/context/hello/info");
response.parse(tester.getResponses(request.generate()));
assertEquals(200,response.getStatus());
assertEquals("<h1>Hello Servlet</h1>",
response.getContent());

See http://docs.codehaus.org/display/JETTY/ServletTester.

New Connectors

SSL Engine connector

A new SSL connector has been added to jetty 6.1 that is based on the javax.net.ssl.SSLEngine class. This allows the asynchronous mechanisms of jetty to be applied to SSL connections, specifically Continuations.

See http://docs.codehaus.org/display/JETTY/Ssl+Connector+Guide

AJP13 connector

Jetty 6.1 now includes an implementation of the apache AJP protocol for forwarding requests from an apache httpd to Jetty. This connector is a significant rewrite from the Jetty 5 connector so more advance IO features can be used.

See http://docs.codehaus.org/display/JETTY/Configuring+AJP13+Using+mod_jk

Grizzly connector

A Grizzly HTTP connector has been added which uses the Grizzly NIO library from Sun’s Glassfish JEE server. This connector provides an integration path into Glassfish server and an alternative HTTP connector.

See http://docs.codehaus.org/display/JETTY/Grizzly+Connector

Integrations

Apache Geronimo

Jetty 6.1 is integrated with Apache Geronimo. The flexibility of Jetty allows for a very close integration with the core geronimo infrastructure.

See http://docs.codehaus.org/display/JETTY/Geronimo

WADI Clustering

WADI is a clustering system that is integrated with both Jetty 6 standalone and as Jetty 6 within Geronimo.

See http://wadi.codehaus.org/

JBoss

Jetty 6 has been integrated with JBoss 4 and is an alternative webtier that will provide Servlet 2.5 and asynchronous servlets within this popular J2EE server.

See http://docs.codehaus.org/display/JETTY/JBoss

GWT

The Google Widget Toolkit needs some small extentions in order to be able to be used with Jetty Continuations. This has been done to great effect on the aployr.com games sites, with gpokr.com and kdice.com games both being run from a single Jetty server capable of handling many more simultaneous users than the previous dual apache+tomcat configuration.

See http://docs.codehaus.org/display/JETTY/GWT

Windows service

A windows service wrapper module is included in jetty 6.1.

See http://docs.codehaus.org/display/JETTY/Win32Wrapper

Works in Progress

Annotations, Resource Injection and LifeCycle Callbacks

The release of Jetty 6.1 includes support for web.xml based resource injections and lifecycle callbacks as defined in the 2.5 Servlet Specification.

Resource injection removes the need for certain servlet-related classes to perform explicit JNDI lookups to obtain resources.
Instead, a resource from JNDI is automatically injected into
designated fields and/or methods of the class instance at runtimeby Jetty.

Lifecycle callbacks allow certain servlet-related class instances
to nominate a method to be called just before the instance goes
into service and another to be called just before the instance
goes out of service.

This release supports these features when defined in the web.xml
descriptor. For example:

<resource-ref>
<res-ref-name>jdbc/mydatasource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<injection-target>
<injection-target-class>com.acme.JNDITest</injection-target-class>
<injection-target-name>myDatasource</injection-target-name>
</injection-target>
</resource-ref>
<post-construct>
<lifecycle-callback-class>com.acme.JNDITest</lifecycle-callback-class>
<lifecycle-callback-method>postConstruct</lifecycle-callback-method>
</post-construct>
<pre-destroy>
<lifecycle-callback-class>com.acme.JNDITest</lifecycle-callback-class>
<lifecycle-callback-method>preDestroy</lifecycle-callback-method>
</pre-destroy>


Resource injection is supported for env-entry, resource-ref and resource-env-ref
elements. Both post-construct and pre-destroy callbacks are also supported.
The 2.5 Servlet Specification also allows for these features to be defined
directly in the source code of servlet-related classes via java annotations.
A forthcoming release of Jetty 6.1.x will implement @Resource, @Resources, @PostConstruct,
@PreDestroy, @DeclaresRoles and @RunAs annotations.

Client API

The protocol engines of Jetty have been refactored so that as well as request parsing and response generation, they now support request generation and response parsing. This will allow a HTTP client API to be developed within Jetty to efficiently implement non-blocking proxies.

Jetty Hightide

The extensive features of Jetty 6.1 are further enhanced and
extended in the Jetty Hightide release from Webtide
Hightide is a versioned and supported distribution of Jetty providing:

  • Jetty 6.1 scalable HTTP server, servlet container and Ajax support, patched with performance enhancements available with a targeted distribution.
  • JettyPlus JNDI framework and JEE services.
  • Access to Webtide’s premium support services.
  • Atomikos XA transaction manager.
  • AMQ with AJAX support configured and integrated into the XA transaction manager.

See http://www.webtide.com/products.jsp

Jetty 6.1.0 Release

6 thoughts on “Jetty 6.1.0 Release

  • January 6, 2007 at 4:48 pm
    Permalink

    Congradulations. Looking forward to trying out what seems like a significant release!

  • January 27, 2007 at 4:32 pm
    Permalink

    Java and logging!…I have noticed with version 6 that there is now (another) dependency on logging. Is there a reason for not using the actual Java built in logging API? I know that many developers out there seem to want to create their own logging implementation and the SLF4J just seems like another layer on top that does not need to exist…Why not just write some simple facades on the front of Commons logging and Log4j (The most used logging implementations) that then link back into the Java logging framework…these can then be instantiated at run time and all logging gets routed through the Java logging API….Any new code can just use the Java APIs thus removing another need to re-invent the wheel!…(Its not just SLF4J but also another mortbay logging layer on top…so what is now happening is that we have mortbay logging, Log4j and commons logging all existing in the same project build!)

    I know the logging APIs came after Log4J/Commons logging but now they are here why not start using them? They always seem to take back stage and I think it would be better to start using them and begin the shift away from multiple Logging frameworks….

  • March 27, 2007 at 4:54 am
    Permalink

    Congratulations for Jetty 6, It’s a great web container.

    But I am disapointed too with the log engine. Why you don’t use the log4j or jdk log ?? Why another !! It? a lot of log engines and all of them makes the same of log4j with litle differences.

    I can’t migrate my app to Jetty because I do not find a way to do the log output of jetty join the log output of my webapp that uses log4j.

    If someone have a clue, workaround, etc, please send-me urgent ! Thanks a lot in advance.

  • April 13, 2007 at 9:52 am
    Permalink

    I’ve just tried out Jetty for the first time, coming from a Tomcat background. One thing that I haven’t found out about is automatic redeployment when the WAR file is updated.

    From what I can tell, automatic redeployment is only available if the webapp has a context file under contexts/ which can be touch’ed/written to, and there’s no way to listen for updated WAR files?

    Another thing that I see is that it appears that the JNDI context becomes unavailable if eg one Resource definition that the application expects is missing. Normally, I’d expect an exception, but the application should still be able to see other JNDI resources.

  • August 27, 2007 at 8:53 pm
    Permalink

    Yes yes. This is always the bit that flumoxes me about jetty. I tear my hair out about this every month or so and then give up and deploy to tomcat.

  • August 29, 2007 at 10:06 pm
    Permalink

    The first thing to do is to upgrade to the most recent jetty, which at the time of this reply is jetty 6.1.5.

    Then I’d recommend, if you haven’t already, that  you take a look at the wiki page all about logging in jetty:

    http://docs.codehaus.org/display/JETTY/Debugging

    Finally, if you’re still having trouble then you can always email the jetty community mailing lists at jetty-support@lists.sourceforge.net.

    Of course, if you’d rather communicate with a Jetty expert privately, then Webtide would be only too happy to discuss support with you 🙂

    cheers
    Jan

Comments are closed.