DO NOT REPLY [Bug 7082] - Calling an RMI Server from a servlet produces stack trace

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-08-28 12:29 ---
Bug in WebappClassLoader where external repositories is now fixed (4.1.10) and 
allows RMI with remote objects to work. This is actually better than 
setting 'java.rmi.server.codebase', because it will only affect the one 
webapp. The following code should be used to set up the remote repository:

// This stuff is for Tomcat 4.1.10 and above.
Method m = null;
try {
ClassLoader cl = StaffPlannerServer.class.getClassLoader();
Class clc = cl.getClass();
if (clc.getName().equals("org.apache.catalina.loader.WebappClassLoader")) {
Class[] classes = new Class[1];
Object[] parms = new Object[1];
classes[0] = String.class;
parms[0] = codebase_url;

m = clc.getMethod("addRepository", classes);
m.invoke(cl, parms);
}
}
catch (Exception e) {}

// And if we're running Tomcat 3.x or a different AppServer completely. Do it 
the old way.
if (m == null) {
Properties p = System.getProperties();
p.put("java.rmi.server.codebase", codebase_url);
System.setProperties(p);
}

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7082] - Calling an RMI Server from a servlet produces stack trace

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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.  Clear

DO NOT REPLY [Bug 7082] - Calling an RMI Server from a servlet produces stack trace

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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-03-27 13:44 ---
Forgot to mention:

There is a problem with the JDK and spaces in the path, but if TC4 is 
installed in a directory without spaces then it still doesn't work.
The test case shows this problem.
Basically the difference between TC3.3 and TC4 is that the rmi server scans 
the Tomcat classpath for TC4 but scans the java.rmi.codebase path for TC3.3.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7082] - Calling an RMI Server from a servlet produces stack trace

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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-03-27 13:32 ---
During the production of this test case another problem was found. If the 
class to be downloaded is in a jar file in the WEB-INF/lib directory then 
everything works, but if the class is in the WEB-INF/classes directory then 
the ClassNotFoundException is thrown.
Classes in lib should not be available to an RMI server, this is a security 
problem.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7082] - Calling an RMI Server from a servlet produces stack trace

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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-03-27 13:31 ---
Created an attachment (id=1434)
The test case to reproduce this bug

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7082] - Calling an RMI Server from a servlet produces stack trace

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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-03-13 17:39 ---
I thought it was a bug in the JDK, but I tried it in TC3.3 with a space in the 
path and it worked.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7082] - Calling an RMI Server from a servlet produces stack trace

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Major   |Normal



--- Additional Comments From [EMAIL PROTECTED]  2002-03-13 17:16 ---
Well, the error strongly hints at the Sun RMI classes incorrectly dealing with 
spaces in the path. This should have an obvious workaround (install Tomcat in a 
path without spaces, as you would do on Unix). Fixing the bug could be complex. 
If you're really interested in having this fixed quickly, you should try to 
debug it further.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: