| One pager template version: 1.9 1. Introduction
1.1. Project/Component Working Name:
Jersey 1.2. Name(s) and e-mail address of Document Author(s)/Supplier:
japod@java.net 1.3. Date of This Document:
04/26/11 2. Project Summary
2.1. Project Description: Grizzly 2 support Multiple Jersey versions support Fix EJB integration Non-blocking asynchronous client Apache HTTP Client 4 support REST client injection
JMX monitoring interface 2.2. Risks and Assumptions: We presume OSGi features allow us to properly separate various
Jersey versions, so that non-privileged end-users could run multiple Jersey versions in parallel
in the runtime. If that assumption is wrong, the end-user still needs administrator
access to GlassFish to correctly separate Jersey versions. EJB integration done in the previous GF version lacks support
for certain use-cases. We are going to fill the gap, but it is not clear
if there are some more "yet to come" use-cases missing. 3. Problem Summary
3.1. Problem Area: a) Integration with Grizzly 2 b) Deployment of multiple versions of Jersey-based applications to GlassFish. c) Improved integration with Java EE 6. d) Better REST client story. e) Diagnose issues with in-production running JAX-RS applications. 3.2. Justification: ad a) GlassFish 3.2 is based on Grizzly 2. REST administrator API spawns it's own
Grizzly server inside GlassFish container and is using Jersey on top of it.
Grizzly 2 Jersey integration is a must have to support this. ad b) Enables developers to use the latest stable version of Jersey when a lesser version
is installed in GlassFish without having administrator privileges.
This is mainly important for hosted environments. ad c) Smooth integration of Java EE 6 components gives developers a better experience. ad d) Increasing number of web services act as a client to other services.
There is also a big demand for more advanced client features like caching, asynchronous
processing, connection control, etc. which needs to be addressed. ad e) Analysis of in-production running JAX-RS applications can help diagnose system performance
issues. 4. Technical Description:
4.1. Details: Jersey server module in GFv3.1 has integrated Grizzly 1 support together
with support for other containers. Grizzly 1 support will be
pulled out and provided as a separate module. Another such module
will be introduced to contain Grizzly 2 integration code. Deployment of Jersey applications to GlassFish as an OSGI-bundle
enables to include a concrete Jersey version in the application bundle
OSGi headers to specify which Jersey version is required.
Unfortunately, Jersey server module uses generic DynamicImport-Package: *
header to be able to load application classes. This dynamic import clause
breaks clean version separation, as Jersey is provided in a multi-modular
fashion. We will remove the dynamic import clause and introduce a pluggable
mechanism to allow Jersey to utilize OSGi means when loading application classes.
Another fix will be needed in the JSON module, where for different
Jersey supported notations different JAXB versions are needed.
This is currently work-arounded using the OSGi optional resolution option.
The workaround is not sufficient, and to fix this, we will need to modularize
Jersey JSON support and introduce a separate OSGi bundle for each JSON notation. Jersey needs to improve it's integration with EJB to address
use-cases where the EJB beans implement local and/or remote interfaces.
Jersey currently uses Java reflection API when dispatching
requests to resource methods. In the above specified
case, the final method invocation call fails, as Jersey tries
to utilize Java method from the original resource class whereas
GlassFish injects a proxy to the local/remote interface implementation
with no other binding to the resource class method.
To fix this, we are going to introduce a new pluggable point,
where it should be able to tweak the final method
invocation code. We are going to do some research in the client area
and based on that we might introduce Jersey client API additions
to address the most demanded client features, like having complete
support for asynchronous request processing and the ability to
control/specify used thread pool. Jersey already has DTrace probe support for resource matching.
Based on a WLS requirement we are going to introduce an additional monitoring SPI,
which could be further utilized also in GlassFish.
We are also going to introduce a simple JMX layer on top of the new monitoring SPI
to enable container agnostic diagnosis. 4.2. Bug/RFE Number(s): https://github.com/javaee/glassfish/issues/13165https://github.com/javaee/glassfish/issues/13236https://github.com/javaee/glassfish/issues/16199 4.3. In Scope:
N/A 4.4. Out of Scope:
N/A 4.5. Interfaces: 4.5.1. Public Interfaces: Grizzly 2 APIs Client APIs Monitoring SPI New OSGi modules 4.5.2. Private Interfaces: Custom Java method invoker SPI for resource method dispatcher Application resource class loader SPI 4.5.3. Deprecated/Removed Interfaces:
None. 4.6. Doc Impact:
TBD 4.7. Admin/Config Impact:
None
4.8. HA Impact:
None 4.9. I18N/L10N Impact:
None 4.10. Packaging, Delivery & Upgrade: 4.10.1. Packaging
None 4.10.2. Delivery Number of the Jersey OSGi modules distributed with GlassFish will increase. 4.10.3. Upgrade and Migration:
None 4.11. Security Impact:
None 4.12. Compatibility Impact
None 4.13. Dependencies: 4.13.1 Internal Dependencies
Grizzly 2.x
4.13.2 External Dependencies
Ning Asynchronous HTTP client which is an open source project licensed under Apache Software License 2.0.
https://github.com/sonatype/async-http-clienthttp://hc.apache.org/index.html
4.14. Testing Impact
Automated tests using the Jersey test framework leveraging JUnit.
Hudson will be be used to continually build and test. 5. Reference Documents: 6. Schedule:
6.1. Projected Availability:
See: TBD |
