Jersey 0.6 is released
By sandoz on Mar 07, 2008
We managed to achieve most things we highlighted in the schedule (more on the missing bits later).
Jakub added improved JSON un/marshaling to JAXB so one can produce JSON from JAXB beans that is much easier to consume by applications like jMaki (see the jMakiBackend example in the Jersey distribution). (I wonder if it is applicable to applications like GWT ?).
We improved on the work Marc did integrating Jersey with IoC containers, like Spring or Guice. Most developer-based things in Jersey are now components that defer to a "component provider" for instantiation and injection. This enables the life-cycle of resource classes to be independent of the IoC container. A developer on the Jersey users list has already experimented with Guice. There are some friction points that still need to be resolved: the main one being constructors where the IoC framework chooses the constructor but only knows about some constructor parameters and Jersey knows about others (especially request-based parameters like those from the request URI).
It is now very easy to register implementations of MessageBodyReader/Writer (the same underlying mechanism scanning for resource classes is reused). Marc and I show (here and here) how such readers/writers can be used with Abdera to create simple Atom-based services.
I promoted the client API used for Jersey unit testing to a public API of Jersey, see here (note that the class ResourceProxy has now been renamed to WebResource as suggested by Stefan Tilkov). This API focuses on the uniform interface constraint and i have found it very productive when writing unit tests. Some of the existing APIs focus on the lower-level request/response which as a consequence makes them more clunky to use. It also borrows from ease of use aspects of JAX-RS and the runtime, especially the message body readers/writers.
Finally i managed to put into code a very simple SPI for plugging in template processors and enabling a flexible model view controller approach. Essentially a resource class can return a template name and a model. The template name gets resolved to a template file in the class path that can be processed by a registered template processor that in turn processes the template with the given the model. I plan to blog about this in more detail later. The Bookstore example in the Jersey distribution provides an example of implicit views using JSPs. A developer on the user list has enabled Freemarker templates in a couple of lines of code and has experimental XSTL translations with JAXB beans (see this thread, which also attempts to explain the difference between implicit and explicit views).
The two areas where we did not make as much progress were adding servlet-based unit tests and evaluating a transition to using Maven.
However, recently on the users list there were requests about using Jetty with Jersey. That gave me just enough information to work things out fairly quickly so now i think we can get good unit tests in place for Jersey's servlet support and increase the code coverage percentages.
As for Maven, we just ran out of time. I believe it is likely to be a significant overhaul of the Jersey build process to transition to Maven and i have heard some Maven-hell stories that make me pause before diving in... so if there are any Maven experts out there with some free time of their hands and would like to help just drop me an email.
In terms of what's next:
- align with 0.7 of the JAX-RS API and fill in all those missing little gaps (this may be a lot of work);
- improve the scope of the JSON support (namely supporting XML attributes);
- refine the MVC and template processor support to manage content types and language;
- (if time permits) experiment with Grizzly and comet;
- (if time permits) provide as part of the Jersey distribution component providers for Guice and Spring. This may be popular judging from the comments we have received; and
- (if time permits) give some more Scala and Groovy TLC to Jersey;