Hi Pavel,
thank you for the investigation. I checked the test case also with the
latest nightly build of 4.0.1. No problems. In contrast the latest
promoted build 4.0.1-b10 still fails on it.
Hence I would like to know if Maven artefacts of the nightly are
available or not? This would be great since my whole development setup
depends on the Maven artefacts of Glassfish.
Best,
Oliver
Am 23.08.13 11:16, schrieb Pavel Bucek:
> 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 git_at_bitbucket.org: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/_at_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:
>>>>>
>>>>>
>>>>> <servlet>
>>>>> ...
>>>>> <init-param>
>>>>> <param-name>jersey.config.workers.legacyOrdering</param-name>
>>>>> <param-value>true</param-value>
>>>>> </init-param>
>>>>> ...
>>>>> </servlet>
>>>>
>>>>
>>>
>>
>>
>