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

Andy Piper andyp at bea.com
Thu Aug 17 05:35:02 EDT 2006


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, 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. 
Using the CCL is also not going to play very nicely in environments 
that already use this feature (e.g. J2EE).

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.


More information about the jsr-291-eg mailing list