Skip to main content

Re: JAX-RS broken when migrating from 3.1.2.2 to 4.0

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
2 replies [Last post]
pavel_bucek
Offline
Joined: 2008-10-24

please see
https://jersey.java.net/apidocs/latest/jersey/javax/ws/rs/core/Application.html#getProperties()

in short - if you are working with Application (or ResourceConfig)
directly, you can set it there, if not, use init or context param,
something like:

...

jersey.config.workers.legacyOrdering
true

...

Regards,
Pavel

On 8/21/13 2:31 PM, Oliver B. Fischer wrote:
> Hi Pavel,
>
> how can I set this property? Never hit this.. ;)
>
> Bye,
>
> Oliver
>
>
> Am 21.08.13 13:43, schrieb Pavel Bucek:
>> Hi Olivier,
>>
>> you might want to send this to users@jersey.java.net, you should receive
>> better answer there (Jersey is JAX-RS Reference implementation used in
>> Glassfish).
>>
>> JAX-RS 2.0 contains change related to precedence of registered
>> providers, so you might be hitting this change. JAX-RS 1.x behavior can
>> be enabled by setting property LEGACY_PROVIDER_ORDERING [1].
>>
>> Getting HTTP status 500 is little strange, I would start with enabling
>> LOGGER org.glassfish.jersey.* (level CONFIG should be enough).
>>
>> Regards,
>> Pavel
>>
>> [1]
>> https://jersey.java.net/apidocs/latest/jersey/org/glassfish/jersey/messa...
>>
>>
>>
>> On 8/21/13 12:27 PM, Oliver B. Fischer wrote:
>>> I have normal ear deployment with an REST interface. The application
>>> works on GF 3.1.2.2 as expected but fails completely on GF 4.0.
>>>
>>> While debugging the problem I mentioned what GF 4 never uses my own
>>> implementation MessageBodyReader while GF 3 it does.
>>>
>>> So, what changed? According to the JAX-RS spec, the container should
>>> iterate through all with @Provider annotated implementations of
>>> MessageBodyReader. If no reader is found, which accepts the request
>>> the container should respond with 415. I always get an error 500.
>>>
>>> BTW, there is nothing in the log files what helps me to figure out
>>> what is going on.
>>>
>>> Any idea? What did I miss?
>>>
>>> Best,
>>>
>>> Oliver
>>>
>>>
>>
>

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
pavel_bucek
Offline
Joined: 2008-10-24

On 8/21/13 11:26 PM, Oliver B. Fischer wrote:
> Hi Pavel,
>
> I set the property, but still get an 500 without any trace in the log
> files.
>
> Thanks for the hint with the logger. I can now see the registered
> providers. My one is also listet. Does the order matter?

yes, but if and only if there is exactly same provider in terms of
effective media type and java type. Is any of your provider method
invoked during request processing? What is in Accept header in your
request? Which media type is produced by your resource method? Do you
have any @Produces/@Consumes annotations on your provider?

Can you extract minimal reproducible testcase and share it? It will be
far more efficient.. :)

Pavel

>
> Best,
>
> Oliver
>
>
>
> Am 21.08.13 15:47, schrieb Pavel Bucek:
>> please see
>> https://jersey.java.net/apidocs/latest/jersey/javax/ws/rs/core/Application.html#getProperties()
>>
>>
>>
>> in short - if you are working with Application (or ResourceConfig)
>> directly, you can set it there, if not, use init or context param,
>> something like:
>>
>>
>>
>> ...
>>
>> jersey.config.workers.legacyOrdering
>> true
>>
>> ...
>>
>
>

pavel_bucek
Offline
Joined: 2008-10-24

Hi Olivier,

nice test case, thanks :)

it works for my on latest glassfish (see attached patch). I do not have
the main cause of this, but basically .. don't use container scanning in
the way you used it. I know there is nothing else in the specification
and you might want to have your application as portable as possible, but
in that case you can implement some simple scanning mechanism and
execute it when Application.getClasses() is called. Or use Jersey
feature which does this for you..

Regards,
Pavel

On 8/22/13 5:16 PM, Oliver B. Fischer wrote:
> Hi Pavel,
>
> The testcase is available at
> https://bitbucket.org/obfischer/glassfish-restproblem/src
>
> Simply clone it and execute Maven
>
> git clone :obfischer/glassfish-restproblem.git
> cd glassfish-restproblem
> mvn
>
> This will build the project and run all tests against GF 3.1.2.2. To
> execute it with GF 4 simple change the Maven property
> dep.glassfish.version from 3.1.2.2 to 4.0
>
> The project also builds an ear you can deploy in GF 3 and GF 4. The
> directory scripts contains a tiny shell script to send an JSON
> document to the REST interface.
>
> Best,
>
> Oliver
>
> Am 22.08.13 10:54, schrieb Pavel Bucek:
>> On 8/21/13 11:26 PM, Oliver B. Fischer wrote:
>>> Hi Pavel,
>>>
>>> I set the property, but still get an 500 without any trace in the log
>>> files.
>>>
>>> Thanks for the hint with the logger. I can now see the registered
>>> providers. My one is also listet. Does the order matter?
>>
>> yes, but if and only if there is exactly same provider in terms of
>> effective media type and java type. Is any of your provider method
>> invoked during request processing? What is in Accept header in your
>> request? Which media type is produced by your resource method? Do you
>> have any @Produces/@Consumes annotations on your provider?
>>
>> Can you extract minimal reproducible testcase and share it? It will be
>> far more efficient.. :)
>>
>> Pavel
>>
>>>
>>> Best,
>>>
>>> Oliver
>>>
>>>
>>>
>>> Am 21.08.13 15:47, schrieb Pavel Bucek:
>>>> please see
>>>> https://jersey.java.net/apidocs/latest/jersey/javax/ws/rs/core/Application.html#getProperties()
>>>>
>>>>
>>>>
>>>>
>>>> in short - if you are working with Application (or ResourceConfig)
>>>> directly, you can set it there, if not, use init or context param,
>>>> something like:
>>>>
>>>>
>>>>
>>>> ...
>>>>
>>>> jersey.config.workers.legacyOrdering
>>>> true
>>>>
>>>> ...
>>>>
>>>
>>>
>>
>
>