users@jersey.java.net

Re: [Jersey] Jersey as pure OSGi bundles

From: Richard Wallace <rwallace1979_at_gmail.com>
Date: Wed, 17 Jun 2009 08:59:33 -0700

On Wed, Jun 17, 2009 at 3:28 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> Hi Richard,
>
> Thanks very much for persisting with this.
>
>
> On Jun 15, 2009, at 2:05 AM, Richard Wallace wrote:
>
>> Hey all,
>>
>> I've done some work on making the Jersey modules real OSGi bundles.
>> I've been doing this work on a branch I created on GitHub
>> <http://github.com/rwallace/jersey-osgi-ified/tree/master>.  I now
>> have the jersey-core, jersey-server and jersey-json loading and
>> working in an OSGi framework (tested on Felix 1.8.0), without having
>> to do any hacks or classloading tricks in application code.  Just
>> create the ServletContainer and go!
>>
>
> Great!
>
> Do you have a simple maven example of how you are deploying? that way i can easily do a full debug cycle :-)
>

I don't currently. But it should be pretty easy to put one together.
I can work on that a bit this evening.

> I have had a brief look at things and i think we need to ensure that OSGi is not a required dependency. Which means re-factoring ServiceFinder appropriately and extending from it,  but i am not sure in OSGi environments how we can bootstrap an OSGi-based implementation of ServiceFinder ?
>

This is already handled. Basically, the modification to the
ServiceFinder only uses the OsgiLocator class. This class has no
dependencies on any OSGi related classes. What happens is that the
BundleActivator installs a BundleListener and registers Callables,
which are used as factories, to the OsgiLocator. So, if you are in a
non-OSGi environment the ServiceFinder will make the call to the
OsgiLocator, but no Callables will be registered so it will simply
return. You also don't need any OSGi classes in your ClassLoader,
because the only class that depends on OSGi framework classes is the
Activator, which will just sit there and not be used or loaded in a
non-OSGi environment. But in an OSGi environment, the Activator will
be used and register factories in the OsgiLocator, so when
ServiceFinder does make the call it will do the right thing.

> See also this issue:
>
>  https://jersey.dev.java.net/issues/show_bug.cgi?id=304
>
> once we get the OSGi stuff in place we should be able to support dynamic bundling of apps. And, i recently modified ServiceFinder to pick up components from META-INF/services/jersey-server-components and META-INF/services/jersey-client-components.
>

I'm a bit confused by that issue. It seems to presuppose that there
is going to be a single Jersey ServletContainer that is created by the
Jersey Activator. I don't think this is a good idea. My use-case is
that I want to have individual bundles that register their own
ServletContainer instances, rather than a single ServletContainer.
Though, after reading it again I may be misunderstanding the
particular use-case described in the issue.

>
>> To do this I used the ServiceMix OSGi Locator code from
>> <https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/locator/src/main/java/org/apache/servicemix/specs/locator/>.
>> I was trying to use it out of the box, but they made the assumption
>> in the BundleFactoryLoader implementation that only a single
>> implementation would appear in the META-INF/services files.  This
>> doesn't work for Jersey, so I had to make some minor modifications to
>> get everything happy.  Other than that, I just added the
>> maven-bundle-plugin to the build of the submodules and cleaned up the
>> Import-Package declarations.
>>
>
> OK.
>
>
>> Another bit of work I had to do was to make the jsr311-api use the
>> ServiceMix OSGiLocator code as well.  I don't have that published at
>> the moment, but if you want me to put it up on GitHub that's easy
>> enough.
>>
>
> That would be helpful to understand what you needed to do. Again we should try and avoid any direct dependencies on OSGi for those that do not require it.
>
> We can modify the JAX-RS 1.1 jar as required.
>

http://github.com/rwallace/servicemix-jsr311-api-1.1/tree/master

>
>> You can see I didn't do all the modules.  I left the jersey-client,
>> jersey-atom, and the jersey-fastinfoset alone.  I didn't try these yet
>> because I don't use them so don't really have a good way to test them.
>> But they should be just as simple as the jersey-json one was, and
>> someone with a way to test that they're really working should be able
>> to get it done quickly enough.  I left the jersey-bundle one alone for
>> similar reasons, thinking that once the smaller modules are done it
>> should be pretty easy to put it all together in the jersey-bundle.  It
>> should really only require pom changes and merging the Import-Package
>> settings of each of the submodules that are included in it.
>>
>
> OK.
>
>
>> Let me know if you have any questions about what I did and how it
>> works!  I'd love to see this included in the 1.1.1 release so I can
>> upgrade from 1.0.2.
>>
>
> We plan to release 1.1.1-ea next week, Fri 26th.
>
> I think there are still a number of open issues that it would be too risky for 1.1.1-ea (plus after JavaOne we took some vacation, so we are really only starting to get back into things proper).
>
> I would like to make OSGi a top priority for the next release (that in addition to Java EE 6 integration) so that we have something for the 1.1.2-ea release, and get something in the 1.1.2.ea-SNAPSHOT as soon as we can so that with resolve all the issues before we release it.
>

Sounds good.

Rich