geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: CORBA/RMI delegates and class loaders
Date Fri, 20 Oct 2006 09:25:47 GMT
Dain Sundstrom wrote:
> One problem I'm seeing in the tck has to do with the CORBA and RMI 
> delegates.  When the java.rmi.Util class is loaded, it uses 
> Class.forName to load the UtilDelegate specified in a system 
> property.  This is what yoko uses:
>
>     private static UtilDelegate delegate = null;
>     private static final String defaultDelegate = 
> "org.apache.yoko.rmi.impl.UtilImpl";
>
>     static {
>         // Initialize delegate
>         String delegateName = 
> System.getProperty("javax.rmi.CORBA.UtilClass", defaultDelegate);
>         try {
>             delegate = 
> (UtilDelegate)Class.forName(delegateName).newInstance();
>         } catch (Exception e) {
>             throw new RuntimeException("Can not create Util delegate: 
> "+delegateName, e);
>         }
>     }
>
>
> IIRC Class.forName(String) uses the class loader of the class 
> containing the code, and since java.rmi.Util will always be on the 
> system class path our delegate must be on the system class path :(
>
> I see a few choices:
>
> * change yoko to use the thread context class loader... then add a 
> gbean to set the property and load the Util class. repeat of every 
> delegate class.
> * write a delegate delegate that allows us to swap out the actual 
> delegate implementation later
> * split out out delegate class into a jar we can put on the system 
> class path
The Class.forName() in Yoko is definitely wrong.  The Util class defines 
a fairly involved search order for loading classes, which it appears 
needs to be used even when loading the Util delegate itself.  This 
shouldn't be difficult to fix.  I've opened a Yoko Jira for tracking 
purposed:

http://issues.apache.org/jira/browse/YOKO-194

Rick


>
> -dain
>


Mime
View raw message