admin@glassfish.java.net

Re: Jersey OSGi issue? Was: Re: dev test for admin cli

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 24 Jun 2010 09:35:00 -0700

On Jun 24, 2010, at 8:03 AM, Jakub Podlesak wrote:

>
> Hi, please see in-line...
>
> On 06/24/2010 04:22 PM, Paul Sandoz wrote:
>> So it is definitely a problem caused due to the change of export
>> headers of the jersey modules, which might require changes to that
>> and/or the admin import.
>>
>> Can you share the code changes you did so Jakub can reproduce.
>>
>> The rules to find a RuntimeDelegate implementation are this:
>>
>> 1) First it tries to find a META-INF/services/
>> javax.ws.rs.ext.RuntimeDelegate and if so will load and instantiate
>> the class
>> whose name is declared in that file; or
>>
>> 2) if 1) fails (and some other lookup techniques) it will try and
>> find a class named com.sun.ws.rs.ext.RuntimeDelegateImpl.
>
> Plus in the OSGi environment, as we did not want to touch the jsr311-
> api.jar, the jersey-server activator [1]
> tries to set the RuntimeDelegate instance via the JSR311 API to
> com.sun.jersey.server.impl.provider.RuntimeDelegateImpl (from jersey-
> server)
> The jersey-client module activator [2] tries to set the delegate to
> com.sun.ws.rs.ext.RuntimeDelegateImpl (from jersey-client).
> But only if it (jersey-client) does not see the jersey-server
> bundle, otherwise tries to activate that to set the RD.
>

But is the activator used for the GF OSGi environment?

Paul.

>>
>> The jersey-server module contains 1) the jersey-client module
>> contains 2). Basically 2) is there when a developer wants to use
>> the jersey-client without the jersey-server being present.
>>
>> What this means is nothing is visible to the admin client.
>>
>> Jakub do we have OSGi related grizzly tests where say the MediaType
>> is accessed by the application before the grizzly container is
>> initialized?
>
> We have a set of tests available at [3] testing various RD setting
> scenarios, but none of them is testing the above mentioned thing.
> I will try to add such a test and also to make others more explicit
> regarding the bundle activation order.
>
> ~Jakub
>
>>
>> Paul.
>>
>> On Jun 23, 2010, at 8:57 PM, Ludovic Champenois wrote:
>>
>>> I played a bit more with jersey 1.3 and removing the dynamic
>>> imports in our rest module.
>>>
>>>
>>> Now getting java.lang.ExceptionInInitializerError
>>> at
>>> org
>>> .glassfish
>>> .admin.rest.LazyJerseyInit.exposeContext(LazyJerseyInit.java:76)
>>> at
>>> org
>>> .glassfish.admin.rest.RestAdapter.exposeContext(RestAdapter.java:
>>> 412)
>>> at org.glassfish.admin.rest.RestAdapter.service(RestAdapter.java:
>>> 166)
>>> at
>>> com
>>> .sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:
>>> 166)
>>> at
>>> com
>>> .sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:
>>> 113)
>>> at
>>> com
>>> .sun
>>> .enterprise
>>> .v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
>>> at
>>> com
>>> .sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:
>>> 803)
>>> at
>>> com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:706)
>>> at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:
>>> 987)
>>> at
>>> com
>>> .sun
>>> .grizzly
>>> .http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:217)
>>> at
>>> com
>>> .sun
>>> .grizzly
>>> .DefaultProtocolChain
>>> .executeProtocolFilter(DefaultProtocolChain.java:135)
>>> at
>>> com
>>> .sun
>>> .grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
>>> at
>>> com
>>> .sun
>>> .grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
>>> at
>>> com
>>> .sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:
>>> 76)
>>> at
>>> com
>>> .sun
>>> .grizzly
>>> .ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
>>> at
>>> com
>>> .sun
>>> .grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:
>>> 57)
>>> at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
>>> at com.sun.grizzly.util.AbstractThreadPool
>>> $Worker.doWork(AbstractThreadPool.java:526)
>>> at com.sun.grizzly.util.AbstractThreadPool
>>> $Worker.run(AbstractThreadPool.java:507)
>>> at java.lang.Thread.run(Thread.java:637)
>>> Caused by: java.lang.RuntimeException:
>>> java.lang.ClassNotFoundException:
>>> com.sun.ws.rs.ext.RuntimeDelegateImpl
>>> at
>>> javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:
>>> 122)
>>> at
>>> javax.ws.rs.ext.RuntimeDelegate.getInstance(RuntimeDelegate.java:91)
>>> at javax.ws.rs.core.MediaType.<clinit>(MediaType.java:44)
>>>
>>>
>>>
>>> javax.ws.rs.core.MediaType class is in jsr311-api.1.1.1.jar
>>> but this jar does not import *anything*, only export packages in
>>> its manifest...and was build on 11/09/2009
>>> How can it find com.sun.ws.rs.ext.RuntimeDelegateImpl ?
>>>
>>> this class is in jersey-client.jar which is not supposed to be
>>> used by our rest admin module anyway...(only for tests)
>>> It is not even exported from this jar.
>>> In fact this jar manifest contains:
>>> Private-Package: com.sun.ws.rs.ext
>>>
>>> So I am not sure at all how this is supposed to work at all...
>>> Please, clarify this before the meeting...
>>>
>>> Ludo
>>>
>>>
>>>
>>>
>>
>