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.
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(...).
Overall the OSGi implementation works very well in my tests. 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.
Cheers,
Mathias
Paul Sandoz wrote:
>
> Hi,
>
> We plan to release Jersey 1.1.5 on the week on Jan 18th.
>
> Jakub is working hard on the OSGi stuff but we want to make sure we
> get it right, and it might require some more soak time in the trunk
> (currently it is in a branch) for other developers to have a play with
> and provide feedback.
>
>
> After that release i am proposing to change the versioning scheme of
> Jersey. Currently we retain the first two numbers as the major and
> minor version of the JAX-RS API Jersey implementations. This is not
> ideal:
>
> 1) Jersey has it's own API that evolves separately it makes it harder
> to signal major, minor, micro status of Jersey itself;
>
> 2) The current versioning scheme does not work very well with maven
> and OSGi, for example 1.1.4.1; and
>
> 3) Then we can consider Markus recommendations for declaring version
> ranges for dependencies.
>
>
> I have been advised that to avoid confusion with the JAX-RS version we
> should choose a version of Jersey that is clearly different. Thus i
> propose that we start the next version at 3.0, even though of course
> it does not really represent a major change.
>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
--
View this message in context: http://n2.nabble.com/Releasing-Jersey-1-1-5-on-the-week-of-Jan-18th-tp4272180p4294945.html
Sent from the Jersey mailing list archive at Nabble.com.