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 13:45:24 GMT
That makes sense, also it is better to remove the codes
ProviderLocator.loadClass from the UtilLoader.loadClass method, or that
makes the function of loadClass method ambigurous.

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

>  On 1/11/2011 7:35 AM, Ivan wrote:
>
> 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 ?
>
>
> I think the static code in the Util class should be something like:
>
>
>          // 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)UtilLoader.loadServiceClass(delegateName, Delegate.class).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;
        }
>
>  Where UtilLoader.loadServiceClass() is a method that functions like
> UtilLoader.loadClass(), but takes both an interface class name that is used
> to qualify the lookup.
>
> Rick
>
> -->
> 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
>
>
>


-- 
Ivan

Mime
View raw message