On Wed, Jan 13, 2010 at 12:11:48PM +0100, Paul Sandoz wrote:
> Hi Mathias,
>
> [Moving to a different thread]
>
> Thanks for looking at this.
>
> Begin forwarded message:
>
> >From: Mathias Brökelmann <mbroekelmann_at_googlemail.com>
> >Date: January 12, 2010 11:29:02 PM CEST
> >To: users_at_jersey.dev.java.net
> >Subject: Re: [Jersey] Releasing Jersey 1.1.5 on the week of Jan 18th
> >Reply-To: users_at_jersey.dev.java.net
> >
> >
> >Hi,
> >
> >I've looked at the recently merged osgi branch and run some tests
> >with it.
> >Here are the things I think could be improved:
> >
> >Personally I think it is better to add the bundle manifest headers
> >to the
> >original codebase and not in separate artefacts. The code which is
> >osgi
> >related - for instance the modifications to the jersey ServiceFinder
> >class -
> >should be inlined into the main artifacts. Otherwise it will be hard
> >on
> >future updates since two codebases must be maintained.
IIRC we wanted to avoid OSGi dependencies in the core artifact,
i would be reluctant to just inline the diffs from the osgi/jersey-core
in the jersey-core for the same reason. I agree the redundant ServiceFinder
class in annoying.
> >
>
> I agree it would be better to avoid such modifications. It might be
> possible to have an OsgiServiceFinder that extends from ServiceFinder,
> and the former is utilized in an OSGi Environment.
That would be an elegant solution. Then we would only need to make sure the ServiceFinder
clients (ServiceProvider class and maybe some others) could obtain the right ServiceFactory
class to call.
>
> We would need to double check that the OSGi headers are also
> compatible with that we currently have for GF support.
These headers are unfortunatelly not 100 % compatible, as in GlassFish
we need to utilize a special private=GlassFish attribute for certain imported packages.
But i do not understand how this relates to the ServiceFinder redundancy thing.
>
> Given it is getting very close to release of Jersey 1.1.5.1 i think we
> need to evaluate this quickly to decide if we should go with what we
> have for 1.1.5.1 or delay it until the next release (which we could do
> rather quickly just for OSGi support).
>
> Jakub, what do you think?
My opinion is to keep the OSGi stuff separated. So to release what we have now
and then keep improving.
>
>
> >IMO modifying RuntimeDelegate of the standard API is not necessary.
> >Jersey
> >could use an Activator in the jersey-server module which creates the
> >jersey
> >RuntimeDelegate instance and inject it into
> >RuntimeDelegate#setInstance(...).
> >
>
> Good point. Same could be done for the client API too, if the delegate
> has not already been set.
>
>
> >Overall the OSGi implementation works very well in my tests.
>
> Great!
+1
>
>
> >I'm currently
> >working on an integration module which tracks
> >javax.ws.rs.core.Application
> >services from the BundelContext and registers an instance of the
> >jersey
> >servlet container for it into an HttpService. This is already
> >working with
> >the current jersey osgi bundles. If you think that this could be a
> >contribution to jersey I would like to do so.
> >
>
> Please, could you share this?
+1,
Thanks,
~Jakub
>
> Thanks,
> Paul.
--
http://blogs.sun.com/japod