On 06/24/2010 06:35 PM, Paul Sandoz wrote:
>
> 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?
That is a very good question. I believe it is the key to the issue.
As GF environment uses the class-loading magic, jersey modules
META-INF/services files are visible to the JSR311 bundle.
We were relying on that functionality until 1.2,
where we used to bundle one big jersey uber jar with GF.
Then we broke jersey down to the individual modules and introduced
the activators, which made jersey to work in a generic OSGi runtime
(testing on grizzly/jetty/felix/equinox).
Now in GF, the two approaches are probably clashing.
I believe the old class-loading magic is still in place?
~Jakub
>
> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>
>