Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Date: 18 Dec 2003 10:08:43 -0000
Message-ID: <20031218100843.28316.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: tomcat-dev@jakarta.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 25528]  -
    WebappClassloader does not register with RMI codebase cache

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=25528>.
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=25528

WebappClassloader does not register with RMI codebase cache


------- Additional Comments From daniel_andefors@hotmail.com  2003-12-18 10:08 -------
Invalid bug?

I think that this bug is invalid as it suggests that the WebappClassLoader 
should “register with the RMI codebase cache”. However, registering every 
WebappClassLoader as a codebase loader will simply cause the getClassAnnitation
(Class) method in sun.rmi.server.LoaderHandler to return the default codebase, 
which is the value of the “java.rmi.server.codebase” system property. This will 
disable the RMI server to dynamically load classes from the web application if 
needed, which might be OK in some situations where the server already has 
access to required classes but should not be considered a valid solution for a 
multi-purpose Container. Moreover, what will happen if running on a JVM not 
provided by Sun? 

I would really appreciate if one of the TC developers (or someone with deeper 
RMI knowledge than me) could comment this.

Thanks,
Daniel

PS: I too have been experiencing performance problems when calling remote 
objects using RMI from within a web application, however, the patch that was 
committed by Remy last week solved my problems (Thanks a lot! :D ). I’d really 
appreciate if this patch was applied for TC4.1 as well (i.e., available in the 
next release).

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org