Forgot to add the links: :-p
[1]
http://fisheye4.atlassian.com/browse/jersey/trunk/jersey/jersey-server/src/main/java/com/sun/jersey/server/osgi/Activator.java?r=HEAD
[2]
http://fisheye4.atlassian.com/browse/jersey/trunk/jersey/jersey-client/src/main/java/com/sun/jersey/client/osgi/Activator.java?r=HEAD
[3]
http://fisheye4.atlassian.com/browse/jersey/trunk/jersey/osgi/runtime-delegate-tests/rd-tests/src/test/java/com/sun/jerseyosgird
Thanks, Jon, for a good catch!
~Jakub
On 06/24/2010 05:03 PM, 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.
>
>>
>> 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
>>>
>>>
>>>
>>>
>>
>