geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@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:48:10 GMT
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 <mailto: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