On Dec 1, 2008, at 10:19 PM, Richard Wallace wrote:
> 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.
>
OK.
>>
>>> 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?
No, it is not. Once an instance of RuntimeDelegate is obtained the
same instance will be returned for subsequent calls to get the instance.
> 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.
>
So one would catch the class not found exception and try with another
class loader?
>>
>>> 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.
>
I am going to ask on the glassfish list what others in in this respect
as well.
> 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.
>
Yes, we plan to split the modules up further.
> 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.
>
OK. I will ping the list when we have the modules correctly OSGI
aligned and we can start experimenting. I suspect that we may into
issues with META-INF/services.
Paul.