geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: Questions on yoko Util class in yoko-rmi-spec should use the interface class as the key?
Date Tue, 11 Jan 2011 12:35:31 GMT
I agree with Forrest that those code logic might need to be updated. From
the codes fragment below of UtilLoader
In the loadClass method, it will first try the ProviderLocator.loadClass,
but what ProviderLocation.loadClass expect is an interface class name, like
javax.rmi.CORBA.Util.
So those codes in the static block of Util, it should first try to load it
from ProviderLocator with service provider interface.
Comments ?
-->
static public Class loadClass(String name, String codebase, ClassLoader
loader)
            throws ClassNotFoundException {
        Class result = null;

        try {
            return ProviderLocator.loadClass(name, null, loader);
        } catch (ClassNotFoundException e) {
            //skip
        }

        ClassLoader stackLoader = null;
        ClassLoader thisLoader = UtilLoader.class.getClassLoader();
        Class[] stack = _secman.getClassContext();
        for (int i = 1; i < stack.length; i++) {
            ClassLoader testLoader = stack[i].getClassLoader();
            if (testLoader != null && testLoader != thisLoader)
            {
                stackLoader = thisLoader;
                break;
            }
        }
        ......
<---





2011/1/11 Rick McGuire <rickmcg@gmail.com>

> On 1/11/2011 4:46 AM, Forrest Xia wrote:
>
>> Hi,
>>
>> When I debug a corba related application, I managed to trace into a piece
>> of yoko code like this:
>>
>> public class Util {
>>    private static UtilDelegate delegate = null;
>>    private static final String defaultDelegate =
>> "org.apache.yoko.rmi.impl.UtilImpl";
>>
>>    // To hide the default constructor we should implement empty private
>> constructor
>>    private Util() {}
>>
>>    static {
>>        // Initialize delegate
>>        String delegateName = (String)AccessController.doPrivileged(new
>> GetSystemPropertyAction("javax.rmi.CORBA.UtilClass", defaultDelegate));
>>        try {
>>
>>            // this is a little bit recursive, but this will use the full
>> default search order for locating
>>            // this.
>> delegate = (UtilDelegate)Util.loadClass(delegateName, null,
>> null).newInstance();
>>        } catch (Throwable e) {
>>            org.omg.CORBA.INITIALIZE ex = new org.omg.CORBA.INITIALIZE("Can
>> not create Util delegate: "+delegateName);
>>            ex.initCause(e);
>>            throw ex;
>>        }
>>    }
>> ...
>>
>> According to another code in ProviderRegistryImpl$SPIRegistry(the id's
>> value is the delegateName variable as highlighted above), while the registry
>> hashmap's key is "javax.rmi.CORBA.UtilClass", that will lead CNF exception.
>> private synchronized BundleProviderLoader getLoader(String id) {
>>            // synchronize on the registry instance
>>            if (registry != null) {
>>                log.fine("registry: " + registry);
>>                // return the first match, if any
>>                List<BundleProviderLoader> list = registry.get(id);
>>                if (list != null && !list.isEmpty()) {
>>                    return list.get(0);
>>                }
>>            }
>>            // no match here
>>            return null;
>>        }
>>
>> So my question is should we change the Util code to pass the interface
>> class name to load class? Please advise.
>>
> I'm not sure I understand the question.  The target class in question here
> is a concrete delegate instance, so I don't understand why you think an
> interface is needed here.  The loading in question here is just for the
> delegate class that is used for the rmi util class.
>
> In any event, you cannot change any of the method signatures for the
> javax.rmi.CORBA.Util class.  That is a standard API class and you can't add
> that.
>
> I think I understand what you wish to do here, and I'd recommend adding a
> loadServiceClass() method to the UtilLoader class and change the initializer
> in Util to use that directly rather than recursively calling
> Util.loadClass().
>
> Rick
>
>
>> Forrest
>>
>>
>>
>>
>


-- 
Ivan

Mime
View raw message