[jboss-jira] [JBoss JIRA] (JGRP-1762) Util.loadClass(): do we use the correct ClassLoader ?

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933094#comment-12933094 ] 

Bela Ban commented on JGRP-1762:
--------------------------------

Comments:

Andre Dietlisheim:
{quote}
>From what I have in mind when packaging libraries to bundles (long time ago, sorry) 1.) will cause havoc to most classpath partitioning frameworks (osgi, jboss modules etc). The code snippet in JGRP-1762 is very likely to fail if bundled. The current thread, your util class and the class you're trying to load may reside in different modules/bundles and visibility rules apply. It is thus is very likely that current thread classloader wont be able to load your class. You should start with 2), the classloader that is accessible via the class you try to load (clazz.getClassLoader() in your snippet).

There are most likely further hints that I have forgotten from those times that others here may come up. Jason Green wrote a nice blog that is describing best practices for module-aware classloading: https://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide
{quote}

Jason Greene:
{quote}
What I can say is the TCCL lookups only make sense if
A) you have a separate API module that discovers a pluggable implementation that the user provides and is discovered lazily during a call from the user's application (e.g. JAXP DOM and STAX)
And 
B) You have a reliable convention that says the TCCL will point to something reliable (like a Java EE container which sets it to the deployment)
{quote}

James Livingston:
{quote}
The correct answer is usually "it depends on what is loading the class
and why".

Is it some shared framework code (JGroups here) which is loading an EE
application class passed to it by name? Is it loading a class from a
name passed over the network to deserialise an object that's about to
follow? Something else? The problem with things like your
Util.loadClass() is that you don't know how it's being used so anything
you do will be wrong in some situations.

Often the best thing to do is to have the API take the classloader to
use as a parameter, and push the decision upwards to the caller who
either knows the search order or can push the decision upwards to their
caller.
{quote}
                
> Util.loadClass(): do we use the correct ClassLoader ?
> -----------------------------------------------------
>
>                 Key: JGRP-1762
>                 URL: https://issues.jboss.org/browse/JGRP-1762
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Investigate whether the code below uses the right classloader. Perhaps we should try to get the classloader of the instances passed to us *before* attempting to use the calling thread's class loader ?
> The current code is:
> {noformat}
>    public static Class loadClass(String classname, Class clazz) throws ClassNotFoundException {
>         ClassLoader loader;
>         try {
>             loader=Thread.currentThread().getContextClassLoader();
>             if(loader != null) {
>                 return loader.loadClass(classname);
>             }
>         }
>         catch(Throwable t) {
>         }
>         if(clazz != null) {
>             try {
>                 loader=clazz.getClassLoader();
>                 if(loader != null) {
>                     return loader.loadClass(classname);
>                 }
>             }
>             catch(Throwable t) {
>             }
>         }
>         try {
>             loader=ClassLoader.getSystemClassLoader();
>             if(loader != null) {
>                 return loader.loadClass(classname);
>             }
>         }
>         catch(Throwable t) {
>         }
>         throw new ClassNotFoundException(classname);
>     }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira