Simon,
I'm going to do some internal checking within Sun on this as well -- I've
only played with RMI a little. The context class loader inside Catalina
web apps is the class loader for that web application, so there might be
conflicts with RMI's assumptions.
I also have a question -- if the classes of the objects you are passing
are themselves loaded from a parent class loader (i.e. from
$CATALINA_HOME/lib) instead of the web app class loader, do you still have
to do the marshalling workaround? I would have expected those classes to
be annotated with a "file:" URL, because they are loaded by a class loader
that uses "file:" URLs for its repository.
Craig
On Fri, 11 May 2001, Bordet, Simone wrote:
> Hello all,
>
> I encounter the following problem using Catalina 4.0b3-4 (while it was
> working with Tomcat 3.2.x).
> I deploy a war containing a servlet and a javabean. From a JSP I invoke the
> servlet, that creates the javabean, that invoke a remote object via RMI
> calling a method that takes an instance of a parameter class as method
> argument.
> In the war I have the servlet in a jar under WEB-INF/lib, and the javabean,
> the stub, and parameter classes under WEB-INF/classes.
> Inside the javabean, I lookup JNDI and obtain a java.lang.reflect.Proxy that
> at the end calls the java.rmi.Remote object passing it the argument.
>
> Now, if inside the proxy I call RMIClassLoader.getClassAnnotation on the
> parameter class, I obtain:
> jndi:/WEB-INF/classes/ jar:jndi:/WEB-INF/lib/xxx.jar!/
>
> This class annotation is written to the RMI stream and when it comes to the
> RMI server side, I got the MalformedURLException: unknown protocol jndi.
> Of course the RMI server side does not know how to handle the jndi: protocol
> of Catalina, and it does have the parameter class in its classpath. Also,
> the RMI server does not run with the SecurityManager.
>
> Another thing that bothers me is that I expected the context classloader to
> load the class in the RMI server (from its classpath), discarding the
> annotated codebase contained in the RMI stream, but this is not the case
> (but maybe I'm missing something).
> Furthermore I got a workaround: if I wrap all arguments into a wrapper
> class, and then the wrapper object into a java.rmi.MarshalledObject, then
> the whole rigmarole works, ie the call arrives to the server (since
> java.rmi.MarshalledObject is not loaded from WEB-INF/classes or WEB-INF/lib
> I have no protocol problems) and then when I call MarshalledObject.get() the
> context classloader loads correctly the classes from the RMI server
> classpath.
>
> Finally this problems happens also when the "RMI server" is JBoss, as
> recently pointed out in the JBoss' mailing list.
>
> Any thoughts ?
>
> TIA
>
> Simon
>
