You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Forrest Xia <fo...@gmail.com> on 2011/01/11 10:46:51 UTC
Questions on yoko Util class in yoko-rmi-spec should use the
interface class as the key?
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.
Forrest
Re: Questions on yoko Util class in yoko-rmi-spec should use the
interface class as the key?
Posted by Forrest Xia <fo...@gmail.com>.
I try making a patch for this problem, pls review. thanks!
Forrest
On Tue, Jan 11, 2011 at 10:39 PM, Rick McGuire <ri...@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 <ma...@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
>> <ma...@gmail.com> <mailto:rickmcg@gmail.com
>>
>> <ma...@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
>> <ma...@gmail.com> <mailto:rickmcg@gmail.com
>>
>> <ma...@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
>>
>
>
Re: Questions on yoko Util class in yoko-rmi-spec should use the
interface class as the key?
Posted by Rick McGuire <ri...@gmail.com>.
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 <ma...@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
> <ma...@gmail.com> <mailto:rickmcg@gmail.com
> <ma...@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
> <ma...@gmail.com> <mailto:rickmcg@gmail.com
> <ma...@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
Re: Questions on yoko Util class in yoko-rmi-spec should use the
interface class as the key?
Posted by Ivan <xh...@gmail.com>.
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 ?
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 <ri...@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 <ma...@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 <ma...@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
Re: Questions on yoko Util class in yoko-rmi-spec should use the
interface class as the key?
Posted by Rick McGuire <ri...@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 <ma...@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 <ma...@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
Re: Questions on yoko Util class in yoko-rmi-spec should use the
interface class as the key?
Posted by Ivan <xh...@gmail.com>.
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 <ri...@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 <ri...@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
Re: Questions on yoko Util class in yoko-rmi-spec should use the
interface class as the key?
Posted by Rick McGuire <ri...@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 <ma...@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
Re: Questions on yoko Util class in yoko-rmi-spec should use the
interface class as the key?
Posted by Ivan <xh...@gmail.com>.
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 ?
-->
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 <ri...@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
Re: Questions on yoko Util class in yoko-rmi-spec should use the
interface class as the key?
Posted by Rick McGuire <ri...@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
>
>
>