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 <[email protected]> > 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 <[email protected]> > >> 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
