You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2002/01/04 07:16:34 UTC

DO NOT REPLY [Bug 5684] New: - WEB-INF/lib jar file loading and operations problems.

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

WEB-INF/lib jar file loading and operations problems.

           Summary: WEB-INF/lib jar file loading and operations problems.
           Product: Tomcat 3
           Version: 3.3.x Nightly
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: Unknown
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: mike@ds808.net


Problem 1:
When a class from a jar file is init'd, the .jar file is somewhat locked.  It 
cannot be deleted or renamed (prevented by os) but it can be overwritten.  The 
only way to delete or rename a jar is to stop tomcat/jvm.  Even a context stop 
or remove does not work.

Problem 2:
Continuing from problem 1, if a jar is overwritten, tomcat recognizes this and 
calls a context remove and add (logged in the stderr log).  But any calls to 
the classes in the jar results in a tomcat 404 error.  Calling a context remove 
and add does not work.  The jar and it's classes are dead until you stop and 
start the tomcat/jvm.

I have many contexts (100+) and I can't bring the tomcat/jvm down to change 1 
jar file in one context.  The /classes and .class files do *not* exhibit this 
problem.  You can delete, rename, and replace class files. As long as we do a 
context remove and add after any changes, everything works perfectly.  The jar 
loading system should work the same way.  BTW, this is the work around to my 
problem, no jar files.  But I don't think that this is the way it was suppose 
to work?

I tested this with 3.3.1 dev 12/31/2001.  The 3.3 final exhibits basically 
identical problems.  I have tested this on 2 different server computers.

Please advise.
Thanks Mike

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>