tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikola Milutinovic <>
Subject RMI classloader issues in TC - second time
Date Sun, 05 Jun 2005 21:48:48 GMT
Hi all.

I have been mucking around this for some time and have some empirical 
data and a question for the list.


I'm building a web client for a RMI client/server application. RMI 
server and client are working from command line. Next I built 
JSP/Servlet which uses that RMI client interface to give web GUI to the 

RMI server: "SearchServerStub implements SearchRMI"
RMI Stub: "SearchServerStub_Stub" (I'm running in JDK 1.5.0, thus no 
"*_Skel" class)
RMI client: "SearchClientRMI"

Whenever my Servlet/JSP executes a method of SearchClientRMI, which has 
this in it:

SearchRMI server = (SearchRMI) Naming.lookup( "rmi://localhost/Search" );

I get a ClassCastException: SearchSearverStub_Stub. I have inspected 
this from a debugger (JBuilder) and the class that is returned from 
"Naming.lookup(...)" is SearchServerStub_Stub", which DOES implement 


Well, fiddling around with the whole setup has given me a situation 
under which this works. If I copy "SearchServerStub_Stub" into 
WEB-INF/classes I do not get the exception.


I can say with 99% certainty that this is a classloader issue. TC sets 
up a classloader for my web-app which reads from WEB-INF/{classes,lib} - 
that I know. RMI has it's own classloader, as it must - that I also 
know. It looks like the class loaded by one classloader cannot mix with 
a class from another. I believe I have read something like that in one 
JBoss article. In this case my local webapp classloader is first 
queried, I guess, and it loads the requested class from it's classpath. 
In unsuccessful case, the _Stub class was loaded by RMI's classloader 
and thus the difference.


Given my situation, what is your recomendation I should do?

I can copy stub classes to the client, but that is awkward and IT IS NOT 
what RMI was intended for. It was intended for transparent and network 
located classloading. If I have to copy RMI stub classes (and, I 
suspect, implementation classes, too) to the client (web application, in 
this case), then I'm better off not using RMI at all. Can someone 
advise? Has anyone been bitten by this?

I think this is mostly intended for the TC developers, not to forget 
JBoss group, too. But, anyone who has insight into this matter is 
welcome. I'm relieved to have a working solution, even if it is a 
patch-quality. I will have to evaluate the applicability of RMI in this 

It could be that I'm doing something wrong here. Just to note, I'm not 
setting on TC anything RMI specific, like "-Djava.rmi.server.codebase", 
only the security policy (and, boy, does that need being relaxed, I had 
to open connection to TCP ports 1024-65535).


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

View raw message