On Mon, Dec 1, 2008 at 2:40 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> Hi Richard,
>
> On Nov 30, 2008, at 1:14 AM, Richard Wallace wrote:
>
>> Hey all,
>>
>> I'm trying to get Jersey working in Felix and I'm running into a few
>> problems.
>
> Is w.r.t. to utilizing Jersey without specific support in GF v3 prelude? for
> example i understand that GF has support for META-INF/services.
>
> We realize we have to do some more work to improve on the OSGi integration.
> For example currently for GF we rely on the jersey-bundle.jar and IIRC
> pretty much every package is exported. The reason being is that although
> Jersey was split into several maven modules the package boundaries between
> them were not cleanly defined. This has been fixed now so that modules only
> depend on API/SPI packages of other modules and there is no package names
> shared between modules. For the 1.0.2 release we hope to add proper OSGI
> information to each module.
>
> If there is any overlap between what you have done and what we would like to
> do perhaps we can share the details on what additional work you needed to
> do?
>
Sorry. I should have described the use-case a bit more clearly. What
I'm trying to accomplish is to embed the Jersey jars within my bundle
and not have any of the Jersey services exported, just have the bundle
be a self contained module that registers a Servlet as a service to be
picked up by the web container.
>
>> I've solved most of them but the one I'm running into now
>> is possibly a showstopper. In the FactoryFinder.find() method of the
>> jsr311-api jar there is this call to get the class loader.
>>
>> classLoader = Thread.currentThread().getContextClassLoader();
>>
>
> The context class loader is used consistently throughout Jersey to
> dynamically load classes: stuff from META-INF/services and classes from
> names when class scanning for root resource and provider classes.
>
My question was more meant to find out if it is used outside the scope
of the initialization? I don't think it is (except for maybe on
reload which I'm not worried about at the moment) because I've managed
to get things up and running pretty well.
>
>> The problem is that the thread class loader is not the bundle class
>> loader so this fails to find the RuntimeDelegationImpl class.
>
> And the RuntimeDelegationImpl will be in another bundle?
>
No, everything that Jersey needs is in the same bundle. The problem
is that the Thread class loader is the application classloader, not
the bundle class loader. In situations like this I've often seen a
policy of trying to find a classloader that can load the requested
class by starting with the getClass().getClassLoader() class loader,
then trying the Thread class loader and finally trying the system
class loader. It seems that that would make sense here as well.
>
>> The
>> simplest solution is to wrap the initialization code in something that
>> sets the threads context class loader to the bundles class loader.
>> I'm worried that even if this works for the startup code, it may cause
>> problems down the line. Any tips?
>>
>
> Hmm... i must admit to not being an expert in the class loading esoteric
> nature of the JVM and how OSGi works in this respect. So it is hard for me
> to know what problems, if any, this might induce. What types of problem
> might you expect? What should i be looking for?
>
I was just wondering if the Thread class loader is used past
initialization is all. It doesn't look like it is and this could be
easily fixed by using the class loader searching I described above.
Another thing that would be nice, while I'm on the subject, is to
split any implementations up. For instance, I'm using the Grizzly web
server but because the httpserver integration code is bundled in the
same jar I have no way of excluding it and have to specifically
configure the maven-bundle-plugin to ignore anything that imports
com.sun.net.httpserver.* which is rather annoying.
I look forward to seeing how things turn out with Jersey 1.0.2 and
making Jersey work better in an OSGi environment. I do have a
use-case coming up where it would be very nice to have a Jersey bundle
deployed which uses the whiteboard pattern so other bundles could
register resources to have them picked up automatically, rather than
having to have to create a separate ServletContainer instance for each
bundle that will want to use Jersey.
Thanks,
Rich