Here is the rmiiiop bug as reported by licensee ATG.



> The PortableRemoteObject.narrow() problem (aka, bug in
> com.sun.corba.ee.internal.util.Utility.loadStub()) (issue #1)
>
> To give you a clearer (I hope) idea of what's going on, I though
> I would describe the setup in which I was trying to get
> PortableRemoteObject.narrow to work().
>
> Excuse the ascii art, but it's the best I could come up with.
>
> Dynamo isolates each J2EE module with it's own ClassLoader that
> contains all the classes unique to that module. If the J2EE
> app contains any EJBs, then all the Modules' ClassLoader's
> have a parent ClassLoader which contain all the EJB client jars of
> all the EJB modules with the J2EE app.
>
> This hierarchy of ClassLoaders prevents the classes
> in one module from colliding with the classes of another module.
> The structure also isolates each J2EE app from all the other J2EE
> apps running within a Dynamo instance.
>
> In the chart below, the different sections represent different
> class loaders. As you move down the chart, you are traversing
> the chain of ClassLoaders towards the root ClassLoader (just
> as one would by calling ClassLoader().getParent()).
>
> The right-hand side of the chart represents the call stack.
>
>
> ----------J2EE Module ClassLoader------------------------
> In Client.java:
> Contains all the com.sun.cts.tests.rmiiiop.
> classes specific ee.Client.setup() {
> to this J2EE module
> // [...]
> CTSNamingContext.lookup(
> Including: "rmiiiop/RMIIIOPServer",
> Client.class RMIIIOPTests.class);
> |
> // [....] |
> ----------ClassLoader for EJB client jar-+--------------
> This class loader |
> contains the stub and |
> interface classes for |
> all the EJB modules |
> in the web-app. |
> |
> Including: |
> RMIIIOPTests.class |
> -----------System ClassLoader------------+---------------
> Contains classes for |
> and CTS util classes. V
>
> Including: In our version of
> our version of CTSNamingContext.lookup(String s, Class
c) {
> CTSNamingContext // [...]
> Object objRef = ctx.lookup(s;
> Object result = objRef;
> if (c != null) {
> result =
>
PortableRemoteObject.narrow(objRef,
> |
c);
> } |
> |
> return |
> result;|
> // [....] |
> |
> |
> |
> -----------Boot ClassLoader (aka "null" class loader)-----
> Contains standard |
> Java/JDK classes, |
> plus RMI-IIOP and JNDI (as |
> needed by the boot-class |
> path option). |
> |
> PortableRemoteObject.narrow():
> // [...]
> Includes classes: Utility.loadStub(Object narrowObj,
> PortableRemoteObject.class | Class narrowTo);
> Utility.class // [....] |
> Class.class V
> Utility.loadStub(ObjectImpl
narrowFrom,
> Class narrowTo):
> // [...]
> Class resultClass =
> loadClassOfType(
> stubName,
> codebase,
>
narrowFrom.getClass().getClassLoader(),
> narrowTo,
>
narrowTo.getClass().getClassLoader());
> // [....]
>
> So... when one finally gets down to Utility.loadStub(), then:
> narrowFrom is an instance of the Class
> com.sun.corba.ee.internal.iiop.CDRInputStream
> (at least toString on the instance returns:
>
"com.sun.corba.ee.internal.iiop.CDRInputStream$1:IOR:000[...]"
> where "[...]" is a long string of hex digits)
>
> It's ClassLoader is the Boot ClassLoader, so
> narrowFrom.getClassLoader() returns null
>
> narrowTo is the Class object
>
org.omg.sub.com.sun.cts.tests.rmiiiop.ee._RMIIIOPTests_Stub
> whose ClassLoader is the Module (top) ClassLoader in
> the chart above.
>
> narrowTo.getClass() returns the Class object
> which represents java.lang.Class
> "java.lang.Class.class" .
>
> narrowTo.getClass().getClassLoader() returns null,
> (for the boot ClassLoader)
>
>
> So... the argument to the call to Utility.loadClassOfType(String,
> String, ClassLoader, Class, ClassLoader) look like:
>
> loadClassOfType(
>
"org.omg.sub.com.sun.cts.tests.rmiiiop.ee._RMIIIOPTests_Stub",
> "http://sailor-venus.atg.com:8830/systemresource/",
> null, null, null);
>
> (I got the above values by adding Println's to Utility.java)
>
> From the these arguments, there's no reference or hook for
> loadClassOfType() method to get access to the top ClassLoader in
> the chart above... I just don't see how it can work, unless the
> "narrowTo.getClass().getClassLoader()" above should be
> "narrowTo.getClassLoader()", which returns the ClassLoader for the
> target Class, which gives us the Module ClassLoader from the chart
> above (and that's what the aim of the code seems to be, at least
> from my own dim understanding).
>
> (*whew!*)
>
> If I make that change, then we pass all the RMIIIOPTests,
> except the 22 failures caused by the rebind issue.
>

alan.frechette@east 2000-08-24