On Fri, Apr 17, 2009 at 2:44 AM, Jakub Podlesak <Jakub.Podlesak_at_sun.com> wrote:
> On Fri, Apr 17, 2009 at 10:17:21AM +0200, Paul Sandoz wrote:
>>
>> On Apr 17, 2009, at 5:57 AM, Richard Wallace wrote:
>>
>>> Awesome, especially the Guice integration. One problem is that the
>>> jersey-bundle doesn't have the OSGi manifest entries.
>>>
>>
>> Jakub can reply with more details, but IIRC we now put the OSGi manifest
>> entries in the jars that are distributed with GF.
>>
>> IIUC Jersey will only work correctly with the GF OSGi container because we
>> rely on additional features like support for META-INF/services.
>>
>> Is that a correct assumption?
>>
>> If not we could put some OSGI manifest entries back in for the bundle?
>>
>> In general it would be nice if we could make all the modules OSGI friendly,
>> including support for META-INF/services for any OSGi conforming container.
>> We would probably require some help in this respect from an OSGi expert :-)
>
> +1
>
> Rich, please let me know, if you are willing to help us in this area.
>
The way I've been using it is a bit hacky, but it works. The only
time that Jersey really needs to be able to access the
META-INF/services in the jersey-bundle is when the WebApplicationImpl
is created and when the ServletContainer.init method is called. So,
what I've been doing is simply creating WebApplicationImpl manually,
wrapped in a block that replaces the thread context class loader with
the Jersey bundles classloader:
ClassLoader loader = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(ServletContainer.class.getClassLoader());
try {
return new WebApplicationImpl();
} finally {
Thread.currentThread().setContextClassLoader(loader);
}
Then, since the ServletContainer.init method if final, I create a
servlet that delegates to the Jersey ServletContainer. But when it
calls the ServletContainer.init method, it uses the same classloader
replacement technique as above around the call.
Due to this I can't use the ClasspathResourceConfig or the
PackagesResourceConfig, but that's ok for me because I'm using Guice
which finds the resources and providers in the Injector.
Anyways, even if the Jersey OSGi integration isn't perfect I don't
think you should throw the baby out with the bath water with the
jersey-bundle jar and remove all the manifest headers.
I'm also curious if you guys ever tried something like is mentioned in
this blog <
http://gnodet.blogspot.com/2008/05/jee-specs-in-osgi.html>.
I know it was brought up on the list before, but it doesn't seem like
anything came of it. If you'd like I can try patching Jersey and see
what happens. But I won't be able to get to it for a while as I'm
heading out on a much needed family vacation today.
Rich
> Thanks,
>
> ~Jakub
>
>>
>> Paul.
>>
>>
>>> Rich
>>>
>>> On Thu, Apr 16, 2009 at 2:15 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>>>> http://blogs.sun.com/sandoz/entry/jersey_1_0_3_is
>>>>
>>>> Paul.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>