DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7082>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7082 Calling an RMI Server from a servlet produces stack trace ------- Additional Comments From [EMAIL PROTECTED] 2002-08-19 09:47 ------- Comments posted to the tomcat-user mailing list by Greg Trasuk [[EMAIL PROTECTED]]: I'm in the same boat trying to use RMI and/or Jini from Tomcat. This isn't a complete answer to your question, as I'm still investigating the issue, but I'm posting what I know so far in the hope that it might help in your own solution, and also generate discussion that will guide my exploration. When all is said and done, if there's interest, I can post a "Catalina-RMI HOWTO" sort of document. Although I didn't try to run the test case that you attached to your bug report, I did take a look at it, and I think I know what's going on. Here's what I know so far (most of which you probably know already, but I'm summarizing for other folks on the list): When you pass an instance of some Serializable class as an argument to an RMI call (e.g. passing a command object, as in your test case), the RMI subsystem will serialize the object with an additional annotation indicating the locations from which the class's bytecode can be downloaded. When you pass an exported object (e.g. a server object or an object that will receive callbacks from remote objects), the RMI subsystem creates and serializes a proxy object (otherwise known as the RMI stub object) in place of the actual object. In either case, the remote RMI subsystem has to load the class that is called out in the serialized instance. It does this by calling the RMIClassLoader. The RMIClassLoader object first tries to find the class locally (i.e. in the default classloader). If it can't find it locally, it searches in the list of locations contained in the annotation mentioned above. If the required class is available locally, no further headaches are caused, which may be why some people have had no problems using RMI under Tomcat - they probably had the serialized classes and/or proxy classes in the standard classpath/classloader setup. And there we find our problem. (At this point you might want to have a look at the JSP snippet below) The annotation is determined by RMIClassLoader. According to the "RMI and Object Serialization FAQ" in the JDK1.31 API docs, "If the _Stub class was loaded by an RMIClassLoader, then RMI already knows which codebase to use for its annotation. If the _Stub class was loaded from the CLASSPATH, then there is no obvious codebase, and RMI consults the java.rmi.server.codebase system property to find the codebase. If the system property is not set, then the stub is marshalled with a null codebase, which means that it cannot be used unless the client has a matching copy of the _Stub classfile in the client's CLASSPATH. " If we're running a standalone application (and I believe also in Tomcat 3.x), we're using the system class loader, which has "no obvious codebase", so the java.rmi.server.codebase property gets used. But what's the class loader used in Tomcat 4.x? I looked at the source code for Tomcat 4.0.1 (happens to be what I have on hand), and o.a.c.loader.WebAppClassLoader extends from o.a.c.loader.StandardClassLoader, which extends from java.net.URLClassLoader, which has a method called getURLs(). The WebAppClassLoader.getURLs() method returns a list of all the repositories it will search when trying to load a class on behalf of the web app. This list calls out all the jar's in WEB-INF/lib, common/lib, etc. Having not seen the source for RMIClassLoader, I suspect that the getClassAnnotation(..) method checks to see if the classloader for the supplied class is a URLClassLoader, and if so, uses the results of the getURLs() method call as "an obvious codebase". This suspicion is supported by the last part of the JSP, where I create a classloader that extends from URLClassLoader but overrides getURLs() to return a phony url. The phony url shows up as the class's annotation. So the exact error you quoted in the bug report shows something about a "protocol missing" MalformedURL exception, which is caused by the fact that the urls to the repositories contain spaces, since the RMI annotation is supposed to be a "space-separated list of URL's". Thus the annotation doesn't get parsed properly. This may be a bug in Catalina's class loader (i.e. should the returned urls have the spaces encoded to '%20'?) or possibly in the way RMIClassLoader uses the results of getURLs(). But it's not the problem. The problem is how to get our codebase into the annotation. Clearly the java.rmi.server.codebase property is not used, since the class loader has a codebase. But setting a system property doesn't feel right to me anyway, since in a webapp scenario, we're in a shared JVM, and we shouldn't be allowed to set system properties that will affect other webapps. (Aside- we similarly can't follow the normal practise of setting our own RMISecurityManager, again since it doesn't play nice with the other webapps. When I tried it, it seemed to screw-up Tomcat's internals, as well. We need to run Tomcat with security enabled, and set the appropriate permissions). Options as I see them: (1)-Use an object factory approach to create instances of classes. If we get the factory object from the RMI server, it and all the instances it creates will have the server's codebase property already set, which skirts the whole issue. It won't allow us to use locally-defined inner classes, however, so it's not great for callback objects (although I suspect we could have the created object call back to a local object) (2)-Load our local classes explicitly through a classloader that returns our codebase. This is what I did in the last part of the test case. It seems like a pain in the butt, and also caused ClassCastExceptions, which is why the reference is to an Object. (3)-Replace the context's classloader with a class loader that adds a webapp-specific codebase to the repositories it lists. I'm thinking of having a property defined in the application context to specify the codebase. There's already provision in server.xml to specify an alternate webapp classloader. Downside is that the application is then Tomcat-specific (not that anyone would want to use any other container...). I suspect that using RMI purely as a client (i.e. with no local objects exported) and passing only instances of classes on the local classpath of both client and server (e.g. java.* classes) would work just fine, with no codebase issues at all, but I've yet to try it out. Ideas and comments, anyone? Greg Trasuk, President StratusCom Manufacturing Systems Inc. - We use information technology to solve business problems on your plant floor. http://stratuscom.ca <test-case apology="I know it's ugly code"> <%@page import="ca.stratuscom.TestWebapp.SampleClass" %> <%@page import="java.rmi.server.RMIClassLoader" %> <%@page import="java.util.Date" %> <%@page import="java.rmi.RMISecurityManager" %> <%@page import="java.net.URL" % > <%@page import="java.net.URLClassLoader" %> <%! private class MyLoader extends URLClassLoader { public URL[] getURLs() { URL retval=null; try { retval=new URL("http://bob/fred.jar";); } catch (Exception e) {} return new URL[] { retval }; } MyLoader(URL urls[]) { super(urls); } } %> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title></title> </head> <body> <h1>Show Annotation for locally created class</h1> <% /* System.setSecurityManager(new RMISecurityManager()); */ String codebase="http://localhost:8080/TestWebapp/TestWebapp.jar";; Date dt=new Date(); /*System.setProperty("java.rmi.server.codebase",codebase);*/ String annotation=RMIClassLoader.getClassAnnotation(dt.getClass()); SampleClass sample=new SampleClass(); String sampleAnnotation= RMIClassLoader.getClassAnnotation(sample.getClass()); %> Annotation for a Date instance is <%=annotation%>. <br> Annotation for a SampleClass instance is <%=sampleAnnotation%>. <hr> <% Class sampCls=RMIClassLoader.loadClass (codebase,"ca.stratuscom.TestWebapp.SampleCl ass"); SampleClass rmiSamp=(SampleClass) sampCls.newInstance(); String localSampAnnotation= RMIClassLoader.getClassAnnotation(rmiSamp.getClass()); %> <br> Annotation for localSamp loaded through RMIClassLoader is <%=localSampAnnotation%> <hr> <% URL codebaseURL=new URL(codebase); URL loaderURLs[]=new URL[] {codebaseURL}; URLClassLoader urlLoader=new URLClassLoader(loaderURLs); Class urlCls=urlLoader.loadClass("ca.stratuscom.TestWebapp.SampleClass"); Object urlSamp= urlCls.newInstance(); String urlSampAnnotation= RMIClassLoader.getClassAnnotation(urlSamp.getClass()); %> <br> Annotation for localSamp loaded through URLClassLoader is <%=urlSampAnnotation%> <hr> <% MyLoader myLoader=new MyLoader(loaderURLs); Class myCls=myLoader.loadClass("ca.stratuscom.TestWebapp.SampleClass"); Object mySamp= myCls.newInstance(); String mySampAnnotation= RMIClassLoader.getClassAnnotation(mySamp.getClass()); %> <br> Annotation for localSamp loaded through MyLoader is <%=mySampAnnotation%> <hr> <address><a href="mailto:trasukg@THINKPAD";></a></address> <!-- Created: Wed Jul 31 09:17:33 Eastern Daylight Time 2002 --> <!-- hhmts start --> Last modified: Fri Aug 09 01:01:14 Eastern Daylight Time 2002 <!-- hhmts end --> </body> </html> -- In SampleClass.java package ca.stratuscom.TestWebapp; public class SampleClass {} </test-case> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
