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 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 ?
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.
> 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.
> 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.
Paul.