This is a discussion on Jersey 1.3 is released - Solaris Rss ; We have recently released version 1.3 of Jersey , the open source, production quality, reference implementation of JAX-RS. The JAX-RS 1.1 specification is available at the JCP web site and also available in non-normative HTML here . For an overview ...
We have recently released version 1.3 of Jersey, the open source, production quality, reference implementation of JAX-RS. The JAX-RS 1.1 specification is available at the JCP web site and also available in non-normative HTML here.
For an overview of JAX-RS features read the Jersey user guide. To get started with Jersey read the getting started section of that guide. To understand more about what Jersey depends on read the dependencies section of that guide. See change log here.
Usually this version would also be placed on the GlassFish Update Center and integrated into the GlassFish M2 release but we hit some last minute glitches with our GlassFish OSGi integration that broke the RESTful admin service. So we are working on fixing that for the next release.
This release only works with Java SE 6 or greater (still eagerly waiting for SE 7!) which greatly simplifies our build and deployment infrastructure. In addition to stopping those annoying compilation issues when developing on SE 6 but compiling on SE 5 (String.isEmpty() i am talking about you)
After seeing too many developers place asserts in JAX-RS/Jersey code to check that injection was working i simply could not stand by any longer. What had been put of for way too long is now implemented in Jersey 1.3 and dependency related errors will occur on deployment. As many errors as possible will be displayed to avoid a compile fix loop.
We added a nice little addition to Guice so that singleton-based provider classes can be injected using the @Inject semantics, see the JerseyServletModule. Unfortunately due to Guice's restriction in binding it is not currently possible to support the @*Params in the same manner. However, IMHO, such extensions using modules is way better than the extensibility approach defined by CDI (see later). All i need to do is find the time to tweak Guice as after having looked at the code i estimate only minor changes to the API and implementation are required.
For the next release, 1.4, we are going to improve the CDI integration. Roberto is doing some seriously impressive Java magic in the Jersey CDI extension class and has it working in a branch. This will mean all JAX-RS artifacts, such as UriInfo and @QueryParam will work with @Inject. CDI has the virtue of being more extensible than Guice (with the set of shoot yourself in the foot implementations being much larger than the set of workable implementations) but IMHO the approach is not modular nor deterministic if one or more extension is present. Or to put it more succinctly: Guice is better. However, CDI is in Java EE 6 so we must make Jersey work well with CDI.
Jakub continues to improve the OSGi integration, which is proving particularly tricky as we are effectively managing 4 platforms: non-OSGI, pure OSGI (tested on Felix), GlassFish OSGi; and Web/war deployment.
Pavel has been making improvements to the test framework and recently added experimental support for JRebel. A sample will be included in the near future.
A new team member, Jon, has joined us to help work on testing, our Hudson infrastructure, and the test framework. He is already up and running tidying up niggles in our inconsistent documentation.
We continue to ensure that Atmosphere, which recently cranked out a 0.6 release with loads of stuff, works smoothly with Jersey. For 0.7 we may have something interesting to say about high-level integration with WebSocket, stay tuned for more details on that (and for a session at JavaOne).
For feedback send email to:
email@example.com (archived here)or log bugs/features here.
Read More about [Jersey 1.3 is released...