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/06/21 17:21:40 UTC

DO NOT REPLY [Bug 10127] New: - tomcat 4.0.4 locks jsp files

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

tomcat 4.0.4 locks jsp files

           Summary: tomcat 4.0.4 locks jsp files
           Product: Tomcat 4
           Version: 4.0.4 Final
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Unknown
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: ashley.smith@hewittbaconwoodrow.com


sun jdk1.4.0_01
tomcat 4.0.4 final
winnt4 sp6a
IE5,6 & Mozilla 0.9.9

using tomcat embedded in our app, we find that tomcat will lock the jsp under 
certain circumstances so the original cannot be edited and saved until tomcat 
is shut down. If we open the jsp source in dreamweaver (or any editor), and 
then view the page via our servlet, we can change the jsp source, hit refresh 
in the browser, and see the changes immediately. However, if we hit refresh 
twice in a row (without making any changes to the jsp source) the jsp becomes 
locked by tomcat, and we can no longer make any changes without either closing 
tomcat down, or deleting the .java and .class files from tomcats work 
directory, as a sharing violation occurs. (this also stops us deleting or 
renaming the jsp)
Using HandleEx (from sysinternals.com), we can see that every time refresh is 
pressed in the browser without changes being made to the jsp, a new handle to 
the file is created and kept open.
I've entered a severity of Major, because our users (mainly web designers) need 
to be able to make changes to a jsp and view the changes immediately, and this 
problem is causing them major delays because they have to keep shutting down 
the jvm, and restarting.

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