On Jun 17, 2009, at 5:59 PM, Richard Wallace wrote:
> 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.
>
OK!
>> 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.
Doh! i was looking at the Activator by mistake.
> 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.
Go it. Do you anticipate any issues utilizing static Map ? perhaps
weak references to classes should be utilized?
> 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.
OK.
>
>
>> 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.
Fundamentally It should be independent of the deployment mechanism and
any deployment bundle i.e. it is just a way to bundle up some resource
and provider classes that could be reused, by another bundle. And that
should now be covered by the support you have defined.
The extra bit is how to listen to when a bundle gets activated/
deactivated, that should also be independent of bundles that register
there own ServletContainer instances, rather than a single
ServletContainer, but it would be dependent on connecting up the
reload mechanism to the ServletContainer instance. I am wondering if
we could provide something in Jersey to make that easier.
>
>
>>
>>> 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
>
Thanks.
>>
>>> 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.
>
OK, once 1.1.1-ea is out the way Jakub and I (once i come back from
holiday trying to kill myself cycling up mountains) will start working
on this.
Paul.