A release candidate of Jetty 7.4 is now available as both Jetty@eclipse and Jetty-Hightide@codehaus distributions. This release contains a number of new features which I will briefly introduce now, and make the target of more detailed blogs, webinars and wiki pages over the next few weeks:
Jetty Overlay Deployer
Jetty now includes a deployer that is designed to allow a war file to be customised and deployed without modifying the original WAR file, which is kept immutable or even signed so that you know it is exactly as delivered. A WAR file is configured by applying a series of overlays, each of which may contain:
- A web.xml fragment to modify or add filter, servlet and other web.xml configuration.
- static content to add or replace static content in the war
- Classes and Jars to be added to the classpath
- Context configuration
Overlays can be created that are application specific, node specific or instance specific and multiple instances of the same application will share the common war and overlays. This sharing includes classloaders and static resource caches and greatly reduces the memory footprint of multi-tenanted deployments.
Overlays also allow easy identification of what configuration has changed in a deployed WAR, so that an overlay can be applied to an updated WAR and the configuration changes will be preserved.
Since almost the beginning, Jetty has had it’s own dependency injection (aka IOC) XML configuration format, which we often refer to as jetty.xml format. This is essentially equivalent to the more popular IOC frameworks like spring XML and Jetty has also been able to be configured and run with spring. However that approach did not allow the context.xml and jetty-env.xml files to be written in spring format, so deployments still had a mix of IOC formats. With Jetty 7.4, the jetty XML configuration format can now detect other formats and will use the java services mechanism to look for a provider for that format. The Jetty-spring module now provides a SpringConfigurationProcessor so that anywhere that a Jetty XML Syntax file is expected, a spring XML file can be used.
Jetty Reverse HTTP
There is an increasing desire to server content of client machines or to run servers from behind restrictive firewalls. An example of this is running a jetty server on an android phone, where the 3G network prevents inbound connections.
Jetty Reverse HTTP uses comet long polling techniques to allow a jetty server to make an outbound connection to a gateway, over which it will receive inbound requests.
Jetty has some compelling features, but sometimes it just is not possible to deploy Jetty. Often this is due to non technical reasons such as a corporate policy that say that only allowable container is LogicalGlassSphere or similar.
Jetty nested makes it possible to deploy jetty within another servlet container by adding a Jetty connector that takes requests/responses from the outer container and turns them into Jetty requests and responses. If permissions allow, Jetty may also open other connectors on other ports, so that as well as outer container requests, jetty can directly serve async HTTP and/or Websockets.
This allows your jetty application to be consumable by corporate policies and deployment procedures, while still giving you access to most of the feature set of Jetty. [ Currently the jetty nested connector does not support non blocking asynchronous requests, but it will eventually support that when deployed in servlet 3.0 containers. ]
Half Close support
Jetty has long used half close when sending content bounded by EOF to avoid the situation where intermediaries handle a TCP/IP RST by discarding all buffered data. But since Jetty is also frequently used in a client and/or proxy role, it has become important that half close is supported inbound as well as outbound. Jetty now supports inbound half closes without an immediate close, so that outbound data can continue to be generated and flushed. This is also integrated with SSL and Websocket closing hand shakes.