CORBA/RMI delegates and class loaders

[Dain Sundstrom <da...@iq80.com>]

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

-dain

Re: CORBA/RMI delegates and class loaders

[Rick McGuire <ri...@gmail.com>]

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
>