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
>
|