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