On Tue, Apr 6, 2010 at 7:25 AM, Jakub Podlesak <Jakub.Podlesak_at_sun.com> wrote:
>
> 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.
I'm building sample app (with lots of tests) that demonstrates bare
bones Spring dm + Jersey with the changes I made to
RuntimeDelegateImpl. As soon as that's ready, I'll submit a patch that
includes all my changes. You guys can decide if it's worth anything :)
I haven't even looked too much at the jersey-spring contrib area, as
at the moment I'm a little more interested making Jersey's internals a
bit more OSGi friendly (which is really just making sure there's lots
of pojos and provider-agnostic DI).
> 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'll try including jersey-core along with jersey-server to see if that
clears up the error and will report back.
> 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.
Thanks for explaining the ServiceIteratorProvider - I missed that
piece. I think it certainly could work to look up services via OSGi,
but I also think it would be cool if the services could be cached a
little (as you've done with the "core" HeaderDelegateProviders) to
prevent iterating over a potentially large list for every service
lookup. My patch will include a suggested way this could work. Again,
you guys can decide if it's any good.
>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>