Hi Adam
I can confirm that things work if the jersey bundles are all activated
before the bundle using jersey is activated. I though I might reproduce the
problem by changing the test for the osgi-helloworld-example but that tests
fails for me even without any modification (using the version at tag 2.21).
There are also other issues with OSGi that can be worked around by tweaking
the order in which bundles are loaded:
https://java.net/jira/browse/JERSEY-2788?focusedCommentId=383931#comment-383931
I think a real solution would require some redesign to actually expose
services so the OSGi environment can make sure Jersey can only be accessed
after it correctly started up (i.e. components depending on jersey are
started after the jersey services and stopped if jersey becomes
unavailable).
Cheers,
Reto
On Fri, Sep 4, 2015 at 1:31 PM, Adam Lindenthal <adam.lindenthal_at_oracle.com>
wrote:
> Hi Reto,
>
> thanks for your analysis. Once you have enough information and ideally a
> reproducible test case, please open an issue in our bug tracker at
> https://java.net/jira/browse/JERSEY/
>
> Regards,
> Adam
>
> On 04 Sep 2015, at 13:17, Reto Gmür <reto_at_gmuer.ch> wrote:
>
> It seems org.glassfish.jersey.internal.ServiceFinder wrongly assumes to be
> running in a non-OSGi environment.
>
> Debugging things a bit I found that OsgiRegistry.getInstance() returns
> null because it is unable to load the Bundlecontext, which is not
> surprising as the jersey-common bundle is not yet active.
>
> I'll try fiddling around with the start levels, but it seems to show the
> limitations of this hybrid service registry approach.
>
> Cheers,
> Reto
>
> On Fri, Sep 4, 2015 at 11:49 AM, Reto Gmür <reto_at_gmuer.ch> wrote:
>
>> Thanks Adam, I will see if I can create a minimum example.
>>
>> But right now I've found another problem which is possibly related: it
>> seems that none of the ForcedAutoDiscoverable instances are actually
>> loaded, at least breakpoint I set at the beginning of the configure-method
>> are never hit. I'm using OSGi so I'm guessing the hk2 bits enabling
>> ServiceLoader is missing, investigating.....
>>
>> Cheers,
>> Reto
>>
>> On Thu, Sep 3, 2015 at 6:28 PM, Adam Lindenthal <
>> adam.lindenthal_at_oracle.com> wrote:
>>
>>> Hi Reto,
>>>
>>> it seems like you are experiencing the same issue as the reporter of
>>> https://java.net/jira/browse/JERSEY-2845 a while ago.
>>> I tried the described behaviour and did not reproduce it. After a while,
>>> it turned out, that the problem was somewhere else on the reporter’s side.
>>>
>>> Could you give it a look in JIRA and and check, that you are not in
>>> similar situation?
>>>
>>> Regards,
>>> Adam
>>>
>>> On 03 Sep 2015, at 18:17, Reto Gmür <reto_at_gmuer.ch> wrote:
>>>
>>> Hello,
>>>
>>> After updating to jersey 2.21 I'm getting 415 responses when submitting
>>> forms unless I add a @Consumes("application/x-www-form-urlencoded"). I'm
>>> using a method with @FormParam annotations.
>>>
>>> According to the spec the absence of a @Consumes-Annotation support for
>>> any media type (“*/*”) is assumed. How comes Jersey is returning a 415
>>> response without this annotation?
>>>
>>> Cheers,
>>> Reto
>>>
>>>
>>>
>>>
>>>
>>
>
>