[jsr-291-eg] Use of the system classloader

Guillaume Sauthier guillaume.sauthier at bull.net
Thu Aug 17 06:02:33 EDT 2006


Andy Piper wrote:
> I am told by the OSGi experts that use of the CCL is a very fragile 
> way of doing these kind of things in OSGi,
Yep
But a lot of libraries are looking classes in the TCCL...

>  however since this issue 
> seems to come up again and again it would be good to have an official 
> recommendation as to the right solution to these kinds of problems. 
>   
I agree :)
> Using the CCL is also not going to play very nicely in environments 
> that already use this feature (e.g. J2EE).
>   
I confirm.

Guillaume
> andy
>
> At 09:39 17/08/2006, Guillaume Sauthier wrote:
>   
>> Hi Andy
>>
>> I haven't noticed any problems by using a JNDI InitialContextFactory 
>> packaged in a bundle (Using Sun VM).
>>
>> But I agree this is an important issue.
>> We're completely stuck if Java SE/EE factories (JAXP, JAX-RPC, SAAJ, 
>> ...) only look for classes inside the System ClassLoader.
>> Sometimes, the factories tries to load from the Thread Context 
>> ClassLoader too, and that helps if we set the TCCL to the bundle 
>> ClassLoader before calling the factory.
>>
>> But this solution doesn't look very good :
>> {snip}
>> // in the Activator
>> ClassLoader old = Thread.currentThread().getContextClassLoader();
>> try {
>>
>> Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
>>  // Call the factory
>>  ...
>> } finally {
>>  Thread.currentThread().setContextClassLoader(old);
>> }
>> {/snip}
>>
>> We're highly dependent on the factory implementation.
>>
>> BTW, Is there any trick for bundlisation of libraries that are 
>> heavily using TCCL for ClassLoading ?
>> It will be great if we can avoid all of the above code...
>>
>> Regards
>> Guillaume
>>
>> Andy Piper wrote:
>>     
>>> Hello Experts,
>>>
>>> Our internal uses of OSGi have come across a number of use cases 
>>> where Java SE relies on the system classloader for loading 
>>> resources of various types. One example is JNDI factories. 
>>> Unfortunately this creates problems when trying to load these 
>>> resources from OSGi bundles. OSGi has already solved this problem 
>>> with the URL Handler Service. This service makes it possible to 
>>> register URL handlers from OSGi bundles, so that there's a way to 
>>> load them other than by putting them in the system class path.
>>>
>>> We would like this issue to be addressed uniformly across Java SE. 
>>> For JNDI this could be solved by providing our own factory 
>>> implementation, I'm not sure whether this mechanism would so 
>>> readily apply to other scenarios however.
>>>
>>> Thoughts?
>>>
>>> andy
>>> _______________________________________________________________________
>>> Notice:  This email message, together with any attachments, may contain
>>> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
>>> entities,  that may be confidential,  proprietary,  copyrighted  and/or
>>> legally privileged, and is intended solely for the use of the individual
>>> or entity named in this message. If you are not the intended recipient,
>>> and have received this message in error, please immediately return this
>>> by email and then delete it.
>>> _______________________________________________
>>> jsr-291-eg mailing list
>>> jsr-291-eg at bundles.osgi.org
>>> http://bundles.osgi.org/mailman/listinfo/jsr-291-eg
>>>
>>>
>>>       
>>
>>
>> _______________________________________________
>> jsr-291-eg mailing list
>> jsr-291-eg at bundles.osgi.org
>> http://bundles.osgi.org/mailman/listinfo/jsr-291-eg
>>     
>
> _______________________________________________________________________
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
> _______________________________________________
> jsr-291-eg mailing list
> jsr-291-eg at bundles.osgi.org
> http://bundles.osgi.org/mailman/listinfo/jsr-291-eg
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: guillaume.sauthier.vcf
Type: text/x-vcard
Size: 558 bytes
Desc: not available
Url : http://bundles.osgi.org/pipermail/jsr-291-eg/attachments/20060817/a14567e8/attachment.vcf 


More information about the jsr-291-eg mailing list