users@jersey.java.net

where are osgi headers from jersey-bundle <was>Re: [Jersey] Jersey 1.0.3 released

From: Jakub Podlesak <Jakub.Podlesak_at_Sun.COM>
Date: Tue, 21 Apr 2009 15:52:46 +0200

On Fri, Apr 17, 2009 at 08:54:12AM -0700, Richard Wallace wrote:
> 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 think you could use

http://download.java.net/maven/2/com/sun/jersey/glassfish/v3/osgi/jersey-gf-bundle/1.1.0-ea-SNAPSHOT/jersey-gf-bundle-1.1.0-ea-SNAPSHOT.jar

i.e.:
<groupId>com.sun.jersey.glassfish.v3.osgi</groupId>
<artifactId>jersey-gf-bundle</artifactId>

in the meanwhile (until we resolve the right osgification)
as a temporary solution.

Would it work for you?
The main difference is the above bundle uses a special private attribute
in imported packages headers for all dependencies (asm, jackson) except jettison.

If this is not going to work for you, i can as a quick hacky "solution" reintroduce
the original headers at com.sun.jersey/jersey-bundle.jar

Please let me know,

~Jakub

>
> 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
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>