When an RMI client passes an application-defined object type to BEA Weblogic server 6.1 running under Merlin, the server is unable to load the correct class definition.

The class in this case comes from a jar file that is loaded with an internal class loader. Resolution of this class happens somewhere within BEA's object input stream class; this resolution happens correctly in Ladybird but fails in Merlin.

A test case is attached. The test case has two modes: one to write a serialized object to a file, and one to read it from the file. To set up the test case, you need two directories: the current directory, and a subdirectory named foo. ClassDescTest.java goes into the current directory; Dummy.java goes into the foo directory. Run the test case in write mode to create the file; then run it in read mode to read the file; reading succeeds with Ladybird but fails with Merlin:

% javac ClassDescTest.java foo/Dummy.java
% java -classpath .:foo ClassDescTest write xxx
% /usr/local/java/jdk1.3.1/solsparc/bin/java ClassDescTest read xxx
resolve class returns class Dummy
Got object Dummy@1fbe93
% /usr/local/java/jdk1.4.0/solsparc/bin/java ClassDescTest read xxx
Exception in thread "main" java.lang.ClassNotFoundException: Dummy
        at java.net.URLClassLoader$1.run(URLClassLoader.java:201)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:189)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:304)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:260)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:214)
        at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:522)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1464)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1388)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1218)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1787)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1713)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1593)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1228)
        at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1552)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1225)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1787)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1713)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1593)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1228)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:299)
        at ClassDescTest$CDTInputStream.<init>(ClassDescTest.java:45)
        at ClassDescTest.main(ClassDescTest.java:117)

As a workaround, the application-defined classes can be added to the server's
classpath (though this may confuse the server's class namespace).

This test is against b72, though it probably exists in earlier builds as well (it's a new release of Weblogic which changes the way they do the serialization, and we didn't test this release against earlier builds).