geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Forrest Xia <forres...@gmail.com>
Subject Re: Questions on yoko Util class in yoko-rmi-spec should use the interface class as the key?
Date Wed, 12 Jan 2011 16:15:09 GMT
I try making a patch for this problem, pls review. thanks!

Forrest

On Tue, Jan 11, 2011 at 10:39 PM, Rick McGuire <rickmcg@gmail.com> wrote:

> On 1/11/2011 9:20 AM, Ivan wrote:
>
>>
>> Hmm, I have to say that I know little about corba, just from the codes of
>> UtilLoader.loadClass, the first part of that method is trying to load an
>> implementation of the SPI, but the left part is just to load the SPI itself,
>> is it the expected behavior ?
>>
> Util.loadClass() is used for a lot more purposes than loading an SPI. The
> problem is occurring because the code is overloading the concepts on to the
> single loadClass() method.  What is needed to fix this problem is a solution
> specific to the task of loading an SPI.
>
> Rick
>
>
>  If we need to look up a specific provider for an interface, maybe it is
>> better to use the similar method suggested by you. which passing both the
>> SPI and defaultImpl class, then we might first try to look up the impl by
>> ProviderLocator, if failed, try to load the default impl by context
>> classloader or stack classloader...
>> Thanks.
>>
>> 2011/1/11 Rick McGuire <rickmcg@gmail.com <mailto:rickmcg@gmail.com>>
>>
>>    On 1/11/2011 8:45 AM, Ivan wrote:
>>
>>        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.
>>
>>
>>    For other reasons, I believe it is still necessary to have
>>    ProviderLocator.loadClass() part of the loadClass() searches.
>>     This is a different, internal situation where we're looking for a
>>    specific provider for an interface.
>>
>>    Rick
>>
>>
>>        2011/1/11 Rick McGuire <rickmcg@gmail.com
>>        <mailto:rickmcg@gmail.com> <mailto:rickmcg@gmail.com
>>
>>        <mailto: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 StringdelegateName=
>>
>>  (String)AccessController.doPrivileged(newGetSystemPropertyAction("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(Throwablee) { org.omg.CORBA.INITIALIZEex=
>>           neworg.omg.CORBA.INITIALIZE("Can not create Util delegate:
>>
>>           "+delegateName); ex.initCause(e); throwex; }
>>
>>           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> <mailto: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
>>
>>
>>
>>
>>
>>        --         Ivan
>>
>>
>>
>>
>>
>> --
>> Ivan
>>
>
>

Mime
View raw message