Hi Eric,
On Tue, Apr 06, 2010 at 08:51:21PM -0700, Eric Hough wrote:
> At OSGi DevCon / EclipseCon this month in Santa Clara, and one of the
> things that the OSGi experts kept reiterating was to *not* program
> directly to the OSGi API (anything from org.osgi.*). Instead they
> recommended using your preferred flavor of declarative services such
> as Spring dm, iPojo, or OSGi DS. See halfway down this interview with
> Jeff McAffer for more on the topic:
> http://java.dzone.com/articles/using-osgi-equinox-effectively.
Another quote from the interview:
"What I mean by that is, write POJOs and use dependency injection style. Too many people have code that reaches all over the place and has OSGi API calls littered throughout. For the most part this makes the code hard to read, hard to test and difficult to reuse in other contexts. Full up Toast has about 80 bundles and only a handful reference OSGi core framework APIs!"
Jersey project now has 137 modules (tests and samples included) and about a tousand
java classes (excluding tests), with only 3 of them using OSGi API calls. These 3 classes are jersey-core,
jersey-server and jersey-client OSGi activators.
>
> With that in mind, I was hoping to learn more about the rationale
> behind Jersey's OSGi activator. I understand the point of it - to
The activators are needed to bootstrap Jersey in an OSGi environment:
- jersey-core activator installs the ServiceMix based ServiceFinder.ServiceIteratorProvider,
to be able to lookup Jersey service providers defined in the META-INF/services files
- jersey-server activator sets the JAX-RS RuntimeDelegate implementation class as needed by JAX-RS API
- jersey-client activator tries to refer to jersey-server activator
to reuse it's RuntimeDelegate implementation if that is available and installs it's own
RuntimeDelegate implementation otherwise (client only scenario)
> install the RuntimeDelegate according to the JAX-RS spec. But I would
Right.
> argue that this could be left up to the Jersey developer to take care
> of as part of the app initialization. Especially if the developer
> wants to replace/modify the default implementation.
I do not understand. Please see the other e-mail referring to replacing
the default ServiceFinder mechanism within Jersey.
Is there anything else you would like to replace/change?
Or doesn't current way suit your needs?
If so, the most helpful would be to provide a test case, which we could eventually
incorporate into the Jersey OSGi test to make sure things work fine with you.
Thanks,
~Jakub
>
> Hope this makes sense, and appreciate any insight here.
>
> Eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
--
http://blogs.sun.com/japod