DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache

[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://issues.apache.org/bugzilla/show_bug.cgi?id=25528

WebappClassloader does not register with RMI codebase cache

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-06-28 22:26 ---
Some further modifications were made by Remy before the 5.0.17 release that 
should address your cache validity concerns in TC5.

I have ported the fix to the TC4 source but there are currently no plans a TC4 
release.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache

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

WebappClassloader does not register with RMI codebase cache





--- Additional Comments From [EMAIL PROTECTED]  2003-12-19 09:21 ---
Yes I agree with you Daniel. The caching of getURLs() as done by Remy in TC5 is 
a good enough fix that does not mess with the delicate communication between 
tomcat classloaders and RMI.

However, the fix by Remy in 5 simply caches the urls array. Remy, what if 
someone calls addJar etc. after the cache has been initialized? Several methods 
will add/remove jars from the list and should be updated in the cache?

Who will post the fix to tomcat 4.1? My company needs a new official version 
with a cached url list to recommend to upgrade to.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache

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

WebappClassloader does not register with RMI codebase cache





--- Additional Comments From [EMAIL PROTECTED]  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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache

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

WebappClassloader does not register with RMI codebase cache





--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 09:06 ---
OK thanx will do. I will keep an eye on tomcat 4.1 patch and recommend our 
clients to upgrade to that version. Until then, we will use current patch.

thanx for the quick response (no support for bugs in tomcat, that's what i keep 
hearing. try to get this addressed to the right people for weblogic ;-)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache

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

WebappClassloader does not register with RMI codebase cache





--- Additional Comments From [EMAIL PROTECTED]  2003-12-16 18:56 ---
Porting the getURLs patch from TC 5 is very easy. I recommend you do that, and I
also expect the patch will be ported to 4.1.x.

BTW, making the amount of calls zero is not useful: the overhead will now be on
the serialization.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache

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

WebappClassloader does not register with RMI codebase cache





--- Additional Comments From [EMAIL PROTECTED]  2003-12-16 09:37 ---
Ah I see the fix now in Revision 1.28 of WebappClassLoader, just a week ago.

It does not solve the superfluous number of calls to getURLs() though, just 
makes it faster.

What should we do with our clients that use tomcat 4 and face this problem? Use 
our custom classloader patch?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache

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

WebappClassloader does not register with RMI codebase cache





--- Additional Comments From [EMAIL PROTECTED]  2003-12-16 09:12 ---
we tested this on tomcat 5 too and the problem persists. I just checked the 
5.0.16 source of tomcat catalina; cannot find the fix that you refer to. Where 
exactly should this be?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache

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

WebappClassloader does not register with RMI codebase cache





--- Additional Comments From [EMAIL PROTECTED]  2003-12-16 08:51 ---
The getURLs() method is called too often in tomcat 4. The 
sun.rmi.server.LoaderHandler class has a piece of code like this:

ClassLoader classloader = class1.getClassLoader();
if(classloader == null || codebaseLoaders.containsKey(classloader))
return codebase;
String s1 = null;
if(classloader instanceof Loader)
s1 = ((Loader)classloader).getClassAnnotation();
else
if(classloader instanceof URLClassLoader)
try
{
URL aurl[] = ((URLClassLoader)classloader).getURLs();
(...)

You see; it checks to see if the classloader is 'known', if so this method 
getClassAnnotation returns the codebase directly. If not, it calls the getURLs
() method for EVERY class deserialization! That is because the codeBaseLoaders 
cache does not contain the WebappClassLoader for Tomcat 4.

I still think it's a bug that should be fixed in version 4; or at least made 
known to people because it has high performance impact for all use or RMI with 
tomcat 4 (see usenet for a lot of people with the same problems)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache

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

WebappClassloader does not register with RMI codebase cache





--- Additional Comments From [EMAIL PROTECTED]  2003-12-15 18:16 ---
The problem is already fixed in the Tomcat 5 CVS: it is very easy to optimize
the getURLs method. The idea is that I didn't know this method was used often.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache

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

WebappClassloader does not register with RMI codebase cache





--- Additional Comments From [EMAIL PROTECTED]  2003-12-15 10:01 ---
Created an attachment (id=9574)
overridden classloader that fixes the problem

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]