You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Dain Sundstrom (JIRA)" <de...@geronimo.apache.org> on 2006/10/20 03:19:34 UTC
[jira] Created: (GERONIMO-2510) CORBA/RMI delegate code requires
delegate implementation to be on the system classpath
CORBA/RMI delegate code requires delegate implementation to be on the system classpath
--------------------------------------------------------------------------------------
Key: GERONIMO-2510
URL: http://issues.apache.org/jira/browse/GERONIMO-2510
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: CORBA
Reporter: Dain Sundstrom
When the java.rmi.Util class is loaded, it uses Class.forName to load the UtilDelegate specified in a system property. This is what yoko uses:
private static UtilDelegate delegate = null;
private static final String defaultDelegate = "org.apache.yoko.rmi.impl.UtilImpl";
static {
// Initialize delegate
String delegateName = System.getProperty("javax.rmi.CORBA.UtilClass", defaultDelegate);
try {
delegate = (UtilDelegate)Class.forName(delegateName).newInstance();
} catch (Exception e) {
throw new RuntimeException("Can not create Util delegate: "+delegateName, e);
}
}
IIRC Class.forName(String) uses the class loader of the class containing the code, and since java.rmi.Util will always be on the system class path our delegate must be on the system class path :(
I see a few choices:
* change yoko to use the thread context class loader... then add a gbean to set the property and load the Util class. repeat of every delegate class.
* write a delegate delegate that allows us to swap out the actual delegate implementation later
* split out out delegate class into a jar we can put on the system class path
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2510) CORBA/RMI delegate code requires
delegate implementation to be on the system classpath
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-2510?page=comments#action_12443676 ]
David Jencks commented on GERONIMO-2510:
----------------------------------------
I'm not convinced your analysis is correct since I believe this worked before I moved the openejb corba classes into a separate jar. I'll look into it further.
> CORBA/RMI delegate code requires delegate implementation to be on the system classpath
> --------------------------------------------------------------------------------------
>
> Key: GERONIMO-2510
> URL: http://issues.apache.org/jira/browse/GERONIMO-2510
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: CORBA
> Reporter: Dain Sundstrom
>
> When the java.rmi.Util class is loaded, it uses Class.forName to load the UtilDelegate specified in a system property. This is what yoko uses:
> private static UtilDelegate delegate = null;
> private static final String defaultDelegate = "org.apache.yoko.rmi.impl.UtilImpl";
> static {
> // Initialize delegate
> String delegateName = System.getProperty("javax.rmi.CORBA.UtilClass", defaultDelegate);
> try {
> delegate = (UtilDelegate)Class.forName(delegateName).newInstance();
> } catch (Exception e) {
> throw new RuntimeException("Can not create Util delegate: "+delegateName, e);
> }
> }
> IIRC Class.forName(String) uses the class loader of the class containing the code, and since java.rmi.Util will always be on the system class path our delegate must be on the system class path :(
> I see a few choices:
> * change yoko to use the thread context class loader... then add a gbean to set the property and load the Util class. repeat of every delegate class.
> * write a delegate delegate that allows us to swap out the actual delegate implementation later
> * split out out delegate class into a jar we can put on the system class path
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2510) CORBA/RMI delegate code requires
delegate implementation to be on the system classpath
Posted by "Rick McGuire (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-2510?page=comments#action_12443759 ]
Rick McGuire commented on GERONIMO-2510:
----------------------------------------
I believe his analysis is (mostly) correct. The specification for javax.rmi.CORBA.Util.loadClass() has a fairly involved search order for loading classes, and it appears that this search order is used even when the class getting loaded is the Util delegate itself. In any event, Yoko should not be using Class.forName() to be loading this.
> CORBA/RMI delegate code requires delegate implementation to be on the system classpath
> --------------------------------------------------------------------------------------
>
> Key: GERONIMO-2510
> URL: http://issues.apache.org/jira/browse/GERONIMO-2510
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: CORBA
> Reporter: Dain Sundstrom
>
> When the java.rmi.Util class is loaded, it uses Class.forName to load the UtilDelegate specified in a system property. This is what yoko uses:
> private static UtilDelegate delegate = null;
> private static final String defaultDelegate = "org.apache.yoko.rmi.impl.UtilImpl";
> static {
> // Initialize delegate
> String delegateName = System.getProperty("javax.rmi.CORBA.UtilClass", defaultDelegate);
> try {
> delegate = (UtilDelegate)Class.forName(delegateName).newInstance();
> } catch (Exception e) {
> throw new RuntimeException("Can not create Util delegate: "+delegateName, e);
> }
> }
> IIRC Class.forName(String) uses the class loader of the class containing the code, and since java.rmi.Util will always be on the system class path our delegate must be on the system class path :(
> I see a few choices:
> * change yoko to use the thread context class loader... then add a gbean to set the property and load the Util class. repeat of every delegate class.
> * write a delegate delegate that allows us to swap out the actual delegate implementation later
> * split out out delegate class into a jar we can put on the system class path
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira