|<< Back to previous view|
[GLASSFISH-17074] Jersey picks wrong JAXB Context when Accept: header is missing Created: 20/Jul/11 Updated: 15/Dec/11
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
Win7 Pro SP1 64 Bit de_DE
|Participants:||Jakub Podlesak, mkarg and scatari|
(This problem was already discussed with Jakub Podlesak of the Jersey team. He has a GF3Fail.war which proofs the failure).
When a client does not care of the returned document type, it does not send an Accept: header. So the server is free to decide for a type that it thinks fits best. In case there is NO @Produces annotation found in a resource, and the application containing that resource has registered its own context provider HAVING a @Produces annotation, it is obvious that THIS custom provider shall be used to marshal the returned entity AND to define the use Content-Type: header when responding.
Actually this is not working in GFv3.1.1_b11 as the contained Jersey engine does NOT pick that custom context provider, but instead ALWAYS asks its own JSON context provider to marshal the result. This is working when the declared return type of the resource method is the custom JAXB class (actually it would be more smart to FIRST give the application-defined provider a chance to marshal the response before picking a Jersey-addon, but this is a different story).
But it is NOT WORKING (JSON context says it does not know that entity class) in case the declared return type is javax.ws.rs.core.Response and the actual entity class is to be retrieved from the dynamically provided entity given to Response.ok(CustomClass)! In that case the JSON provider is picked, which says it does not know that class.
As long as the JSON provider is picked by Jersey, it MUST add the dynamically the class found in the actual dynamic response.
A far better solution obviously would be to FIRST ask the application-provided providers to do the marshalling as this obviously is what the application programmer tries to achieve (as he doesn't know of the JSON provider at all).
There are two possible workarounds, which both render unuseable in case neither the code of the client not the code of the WAR is available to the GlassFish v3 administrator. As a result, this is a showstopper for non-programmers and such must get fixed ASAP.
(A) Change the client to always provide Accept: header – Only possible if the GlassFish administrator has control over all users, what is ridiculous in case of public anonymous services. Also this does not reflect the typical web scenario, where a client can safely assume to get back anything as long as the server can send anything (which this server could if not having this bug).
(B) Add @Provides(contentType) to the resource method – Only possible if the GlassFish administrator has control over the WAR's source code, what is ridiculous in case of running third party off-the-shelf applications provides by large ISVs ("We tested with application server XYZ and will not change our WAR just to make it run in your buggy server!").
|Comment by mkarg [ 26/Jul/11 12:22 PM ]|
Any progress here regarding a real fix? I mean, the workaround is nice and simple but enforces a software change either on the client or the server (what to do if one has no access to the source?). There should be a solution that does not need any changes in the application.
|Comment by Jakub Podlesak [ 29/Jul/11 03:14 PM ]|
Lowering the priority to Critical, as there are workarounds for the issue (see above),
I still do not know what is wrong, as (in spite of what's written in the description)
Anyway, it is generally a good practice to use the @Produces annotation in order
|Comment by mkarg [ 01/Aug/11 07:45 AM ]|
As the solution enforces a source code change in the deployed application, this breaks the WORA principle and such IS a showstopper for ISVs. You cannot expect that every GlassFish administrator has full access to the source code of all deployed applications, and you cannot expect ISVs to change their source code (possibly developed with a different JAX-RS product) just to make it run on Jersey.
|Comment by scatari [ 04/Nov/11 10:00 PM ]|
Please evaluate this for possible inclusion into 3.1.2.
|Comment by Jakub Podlesak [ 15/Dec/11 03:40 PM ]|
Excluding from 3.1.2
Please see the reasoning in my previous comment above.
The workaround (A) could still be considered.