Hi Eric,
On Mon, Apr 05, 2010 at 09:32:03AM -0700, Eric Hough wrote:
> Hi,
>
> i've run into a bit of trouble while trying to load a simple Jersey
> application in an OSGi environment (Spring dm + Spring dm Server in my
> case). Using Jersey 1.2-SNAPSHOT.
The jersey-spring module from the contribs area has not been OSGified yet,
we need to fix that. How did you resolve this?
Would you be willing to contribute your application as a test case?
That would be a good start to make sure we cover your use case.
>
> The first problem is when the bundle Activator in jersey-server loads
> up RuntimeDelegateImpl as the RuntimeDelegate instance. Looking at the
> implementation of RuntimeDelegateImpl, I see that it uses the
> META-INF/services service lookup to load up some default
> HeaderDelegates. For some reason, the jersey-server jar has no file in
> META-INF/services named com.sun.jersey.spi.HeaderDelegateProvider,
> which results in zero HeaderDelegates getting loaded into the runtime
> and the app doesn't start (I can report back later with the exact
> error). I was able to copy the missing file from the jersey-core jar
> and the app at least started.
Instead of copying the file from the jersey-core module it should be sufficient
to just add the jersey-core module to your configuration as it is needed anyway
by the jersey-server module. There should be some tests under the osgi subdirectory
covering this area.
>
> I'm a bit of an OSGi purist, and so I want to have any kind of service
> to be loaded by OSGi and not the ServiceFinder mechanism. That way I
> can easily add/remove, for instance, MessageBodyWriters via OSGi. I've
You can still re-use the ServiceFinder mechanism, where you can plug-in
your own ServiceFinder.ServiceIteratorProvider. This is how the behaviour of the ServiceFinder
is changed when Jersey is run in an OSGi environment.
> been tinkering with replacing the RuntimeDelegateImpl with an
> implementation of my own that can be wired up via OSGi (though it's
> still just a pojo).
>
> In an ideal world for me, I'd be able to piece together various pojos
> from Jersey to assemble my own OSGi-based application. Currently this
> isn't really feasible given the somewhat tight coupling (not trying to
> sound snotty or condescending!) of the current impl. I see many areas
> to decrease the coupling, though, and I'd like to help out. Again, I'm
Your help is greatly appreciated!
> not saying that you guys haven't done a great job already! I've been
> messing around with various RESTful frameworks for use in OSGi and I
> think Jersey has the best chance to take the lead in this respect.
>
> So I guess my questions are:
>
> 1. Is the missing
> META-INF/services/com.sun.jersey.spi.HeaderDelegateProvider from
> jersey-server a bug?
No, as mentioned above, the jersey-core provided HeaderDelegateProvider should be sufficient.
> 2. Assuming I've submitted my SCA to Sun, what's the best way to
> supply proposed patches?
You can file a new bug report at [1], and attach your test case together with the patches.
We can grant you commiter rights to the Jersey project later on, to simplify things even more.
Thanks!
~Jakub
[1]
https://jersey.dev.java.net/issues
>
> Thanks!
>
> 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