This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
This exception was found in build 020207: This exception does not happen often. Thu Feb 07 15:57:38 PST 2002: org.openide.filesystems.FSException: Cannot delete file WEB-INF/lib/peterswaerstodog.jar in C:\workbase\f4j_all\f4jbuild\firststart\develop\sampledir\wmtest. org.openide.filesystems.FSException: Cannot delete file WEB-INF/lib/peterswaerstodog.jar in C:\workbase\f4j_all\f4jbuild\firststart\develop\sampledir\wmtest. at org.openide.filesystems.FSException.io(FSException.java:78) at org.openide.filesystems.LocalFileSystem.delete(LocalFileSystem.java:321) at org.netbeans.core.ExLocalFileSystem.delete(ExLocalFileSystem.java:75) at org.openide.filesystems.LocalFileSystem$Impl.delete(LocalFileSystem.java:659) at org.openide.filesystems.AbstractFileObject.delete(AbstractFileObject.java:480) at org.netbeans.modules.web.context.DefaultDataObject.handleDelete(LibJarObject.java:152) at org.netbeans.modules.web.context.LibJarObject.handleDelete(LibJarObject.java:72) at org.openide.loaders.DataObject$2.run(DataObject.java:524) at org.openide.filesystems.EventControl.runAtomicAction(EventControl.java:89) at org.openide.filesystems.FileSystem.runAtomicAction(FileSystem.java:388) at org.openide.loaders.DataObject.delete(DataObject.java:522) at org.openide.loaders.DataNode.destroy(DataNode.java:219) at org.openide.nodes.FilterNode.destroy(FilterNode.java:399) at org.openide.explorer.ExplorerActions$DeleteActionPerformer$DestroyAtomic.invoke(ExplorerActions.java:527) at $Proxy3.run(Unknown Source) at org.openide.filesystems.EventControl.runAtomicAction(EventControl.java:89) at org.openide.filesystems.FileSystem.runAtomicAction(FileSystem.java:388) at org.openide.explorer.ExplorerActions$DestroyInvoker.run(ExplorerActions.java:568) at org.openide.explorer.ExplorerActions$DeleteActionPerformer.doDestroy(ExplorerActions.java:494) at org.openide.explorer.ExplorerActions$DeleteActionPerformer.performAction(ExplorerActions.java:463) at org.openide.util.actions.CallbackSystemAction.performAction(CallbackSystemAction.java:109) at org.openide.util.actions.CallableSystemAction.actionPerformed(CallableSystemAction.java:69) at org.netbeans.core.ModuleActions$1.run(ModuleActions.java:105) at org.openide.util.Task.run(Task.java:152) [catch] at org.openide.util.RequestProcessor$ProcessorThread.run(RequestProcessor.java:622)
change p5->p2 as it can be reproduced: 1.Mount the web module(see attached war) 2.open testtgl.jsp and compile it. 3.Delete test.jar. The following exception appears: Tue Mar 05 11:10:55 PST 2002: org.openide.filesystems.FSException: Cannot delete file WEB-INF/lib/test.jar in C:\workbase\f4j_all\webadvanced\testbase\testdata\webmodule_test\wm- tagl\wm. org.openide.filesystems.FSException: Cannot delete file WEB- INF/lib/test.jar in C:\workbase\f4j_all\webadvanced\testbase\testdata\webmodule_test\wm- tagl\wm. at org.openide.filesystems.FSException.io(FSException.java:78) at org.openide.filesystems.LocalFileSystem.delete (LocalFileSystem.java:321) at org.netbeans.core.ExLocalFileSystem.delete (ExLocalFileSystem.java:75) at org.openide.filesystems.LocalFileSystem$Impl.delete (LocalFileSystem.java:659) at org.openide.filesystems.AbstractFileObject.delete (AbstractFileObject.java:480) at org.netbeans.modules.web.context.DefaultDataObject.handleDelete (LibJarObject.java:152) at org.netbeans.modules.web.context.LibJarObject.handleDelete (LibJarObject.java:72) at org.openide.loaders.DataObject$2.run(DataObject.java:524) at org.openide.filesystems.EventControl.runAtomicAction (EventControl.java:89) at org.openide.filesystems.FileSystem.runAtomicAction (FileSystem.java:388) at org.openide.loaders.DataObject.delete(DataObject.java:522) at org.openide.loaders.DataNode.destroy(DataNode.java:219) at org.openide.nodes.FilterNode.destroy(FilterNode.java:399) at org.openide.explorer.ExplorerActions$DeleteActionPerformer$DestroyAtom ic.invoke(ExplorerActions.java:527) at $Proxy3.run(Unknown Source) at org.openide.filesystems.EventControl.runAtomicAction (EventControl.java:89) at org.openide.filesystems.FileSystem.runAtomicAction (FileSystem.java:388) at org.openide.explorer.ExplorerActions$DestroyInvoker.run (ExplorerActions.java:568) at org.openide.explorer.ExplorerActions$DeleteActionPerformer.doDestroy (ExplorerActions.java:494) at org.openide.explorer.ExplorerActions$DeleteActionPerformer.performActi on(ExplorerActions.java:463) at org.openide.util.actions.CallbackSystemAction.performAction (CallbackSystemAction.java:109) at org.openide.util.actions.CallableSystemAction.actionPerformed (CallableSystemAction.java:69) at org.netbeans.core.ModuleActions$1.run (ModuleActions.java:105) at org.openide.util.Task.run(Task.java:152) [catch] at org.openide.util.RequestProcessor$ProcessorThread.run (RequestProcessor.java:622)
Change P5->P2.
Created attachment 4949 [details] web module
As Peter Carson pointed out, the deletion deficiency seems to be related to the jsp parser. Here's a way to demonstrate: 1. create a web module; add a tag library from the repository (into WEB-INF/lib). Delete it. It will delete. 2. re-add the tag library; create a jsp in the web module; try, just try, to delete the tag library. It won't. 3. Close the jsp from the source editor. Restart the ide. If there aren't any jsps from the web module up in the source editor, then the tag library can be deleted. Once you edit the jsp in the source editor, the tag library can be deleted no longer. Petr Jiricka and I did some research on this one: the jsp parser uses tomcat 401 code to keep track of tag libraries. In tomcat 401 code, it uses java.net.JarURLConnection to get its hands on the jar files for reading. JarURLConnection (via its superclass URLConnection) caches the jars it reads. This means that the jars are held too long and we can't delete them. There's even a "@@FIXME" comment in the tomcat code saying this, and its effect on tomcat (can't redeploy from same jar). There is a property: useCaches, which allegedly turns off this caching behaviour. Tomcat 401 doesn't use it. There's a bug in the JDK whereby turning off caching behaviour has no effect. We suspect that's why tomcat doesn't use it. That bug was fixed in jdk1.3.1_01 or something like that. We're going to attempt some experiments with tomcat, to see if turning off caching behaviour on the JarURLConnections helps. News at 11. Back to you.
More data: I tried calling conn.setUseCaches(false) in two places in tomcat4.0.1 code that use JarURLConnections: org.apache.jasper.compiler.TldLocationsCache.tldConfigJar(...) and org.apache.jasper.compiler.TagLibraryInfoImpl() (Note that both bits of code have the same "FIXME@@@" comment: // FIXME @@@ // -- it seems that the JarURLConnection class caches JarFile // objects for particular URLs, and there is no way to get // it to release the cached entry, so // there's no way to redeploy from the same JAR file. Wierd. ) With these patches plugged into jasper-compiler.jar in modules/ext, some of the deletion problems stopped happening. THe problem where all you had to do was bring up a jsp inthe source editor to experience deletion deficiency -- that is fixed with this patch. However, if you use code completion on the <%@taglib uri="..." > field, then taglib jars are once again undeletable.
Here is the information from bug #20877, which seems to be a duplicate of this one. ------- Create a taglibrary with a tag that prints "taglib 1" create a tag library jar, put it in a web module's WEB-INF/lib and create a JSP that uses it. Deploy and execute the JSP. Now, stop Tomcat and delete the jar file. Delete the jarContents file. Delete the tag handlers. Generate tag handlers again and make it such that the tag prints "taglib 2". create the tag library jar, put it in the web module, deploy and make your request: you will see "taglib 1". Somewhere along the way, the new version is not overwriting the old version. I have not yet been able to discover a workaround and am thus filing this as a P1 bug. ------- Additional Comments From Petr Jiricka 2002-02-26 08:00 PST ------- I believe this could be caused by the fact that the Tomcat server only reloads the JSP if the JSP itself has been modified since last execution, so it does not pick up any changes in dependent files. I can think of two possible workarounds: 1) Delete the working files under the temp directory of Tomcat or 2) "touch" the JSP file - modify and save it Also, it would be useful to find out what is the behavior of standalone Tomcat server (without the IDE) in this case. ------- Additional Comments From Simran Singh Gleason 2002-02-26 13:55 PST ------- This turns out not to be specific to taglibs. It will happen with any jar dropped into WEB-INF/lib. I reproduced it the following way: - in a web module, create a directory (e.g. "pack"), create a java class "One" in that directory; compile the class. - create a new jar recipe, put the directory (pack) as one of the content members; compile the jar. - outside the ide, copy the jar into WEB-INF/lib; the jar will be mounted. Open it up in the explorer and see the package "pack" with the class "One" inside it. - delete the jar from WEB-INF/lib - remove the class "One" from the directory "pack"; create a new class "Two" in "pack"; compile it. - compile the jar recipe again. Look at the jar outside the ide. It should contain pack.Two but not pack.one. - outside the ide, copy the jar into WEB-INF/lib. wait for it to be mounted; open the mounted jar filesystem in the explorer -- it has pack.One, when it should have pack.Two. This might be related to some other jar behaviour I'm seeing: if two web modules have a copy of the same jar in WEB-INF/lib, only one will be mounted. So maybe there is some mechanism that sees that the name is the same as the old one, and mounts the old one instead. A confirmation of this: I copied the jar that was mounted incorrently into WEB-INF/lib, but under a different name, and the newly named copy was mounted correctly. Also: this happened without starting the tomcat server at all. ------- Additional Comments From Simran Singh Gleason 2002-02-26 17:04 PST ------- Spent more time trying to reproduce this, and the QAs cannot reproduce it. I went back and tried it again and found that it only occurs after certain other problems: 1. When I compile a jar recipe and then copy the jar from the menu on the jar's node inside the jarcontent node, and then paste the jar into WEB-INF/lib, then the resulting jar is length 0 (I've only seen this happen on my system), and then the bug happens. 2. Also, when I delete the jar from WEB-INF/lib, I get the little .nfsNNNN file. This also seems to correlate with this bug happening. (Note that I only seem to be getting the .nfsNNNN thingy after I get the zero length jar problem). 3. I'm only seeing this on solaris, and it happens to be solaris 7, using jdk1.3.1_01 So, if no one else can reproduce this problem it's probably not a P1. ------- Additional Comments From Petr Jiricka 2002-02-28 07:18 PST ------- Agreements was reached that this does not need to be fixed for Orion EA. ------- Additional Comments From Peter W Carlson 2002-03-08 14:26 PST ------- This additional behavior was noted by Hong Liu and filed as bug number 21331 build 020306(RC3) To reproduce: 1.create a web module. 2.create a taglibrary 3.add tag test1 to the taglibrary and create the taglibrary. 4.add the taglibary to the web module. 5.create a jsp file to use the test1 tag. It works fine. 6.add tag test2 to the taglibrary and create the taglibrary. 7 add the new taglibrary to the web module. The NEW taglibrary is added as it can be verified by extending the jar node. 8. modify the jsp to use the new tag test2. 9. compile the jsp There is error:No such tag test2 in the tag library... I tried to dismount/mount the web module, but it could not help. Restarting the ide, then it helps. Note: a workaround has been found! When developing a tag library, create the taglibrary (.tld file) in your web module's WEB-INF/lib directory. Additionally, set the tag handler generation root to WEB-INF/classes. In a .jsp file which is using the tag library, either refer to the URI as "/WEB- INF/lib/myTaglib.tld" or make an alias in the deployment descriptor. ------- Additional Comments From Peter W Carlson 2002-03-08 14:29 PST ------- *** Issue 21331 has been marked as a duplicate of this issue. *** ------- Additional Comments From Simran Singh Gleason 2002-03-11 08:15 PST ------- We've found a workaround, and this bug doesn't result in loss of user data or hanging the IDE, so we're lowering the priority to 2. Here is the entry from the release notes: 20877, 20384 Description: Tag library jars cannot be replaced in WEB-INF/lib after parsing and executing JSPs in the web module. The JSP parser, compiler, and/or executor sometimes hold onto pointers to tag library jars in WEB-INF/lib. On Windows this means that the jars intermittently cannot be deleted, resulting in a "Cannot delete file ..." exception. On Solaris, the jars can be deleted, but when they are replaced with new jars, sometimes the compiler "sees" the old version of the jars. To get the correct jar replacement behaviour, you must restart the IDE. This can make a tag library development cycle that involves packaging the tag library jars somewhat unwieldy. The workaround is to develop tag libraries by referencing the TLDs and tag handler classes directly, without packaging the tag library into a jar until the end of the development cycle. 1. Create the tag library in WEB-INF/lib and do all development there. 2. Set the tag handler generation root to the web module's WEB-INF/classes directory. 3. In order to use the tag libraries from a JSP, either directly refer to the taglib URI as "/WEB-INF/lib/myTaglib.tld" or set an alias in the deployment descriptor with a tag library entry.
*** Issue 20877 has been marked as a duplicate of this issue. ***
Waiving this one for FFJ 4.0, per iteam decision.
Waiver approved.
*** Issue 24057 has been marked as a duplicate of this issue. ***
*** Issue 24398 has been marked as a duplicate of this issue. ***
Set target milestone to TBD
Requesting to waive for NetBeans 3.4. Per the description of this but, the cause is the fact that the jar files for which the bug occurs are being used by the JSP parser, which prevents deletion on Windows. The fix is not known, and is non-trivial. Fixing this bug would delay the release significantly.
Would it be possible to make the error reporting nicer, i.e. put a try/catch block around the exception and notify the user via some reasonable message? Give the number of duplicate bugs filed, this seems like a bug that multiple people hit.
approved waiver; keep my name in cc for release note purposes
Yes, it would be desirable to provide a better error message, which would also mention the workaround (sometimes it may help to stop the server if it is running). This is not easily possible in NetBeans 3.4, though. The code has changed in this release since FFJ 4, so the exception trace does not go through WebApps code, so this is not fixable in WebApps modules. See below for the new stack trace of the exception. *********** Exception occurred ************ at Thu Aug 01 17:48:13 CEST 2002 Annotation: Cannot delete file WEB-INF/lib/standard.jar in E:\software\jsr52\jstl-ea30\examples. org.openide.filesystems.FSException: Cannot delete file WEB-INF/lib/standard.jar in E:\software\jsr52\jstl-ea30 \examples. at org.openide.filesystems.FSException.io (FSException.java:91) at org.openide.filesystems.LocalFileSystem.delete (LocalFileSystem.java:272) at org.netbeans.core.ExLocalFileSystem.delete (ExLocalFileSystem.java:77) at org.openide.filesystems.LocalFileSystem$Impl.delete (LocalFileSystem.java:563) at org.openide.filesystems.AbstractFileObject.delete (AbstractFileObject.java:490) at org.openide.loaders.FileEntry.delete (FileEntry.java:100) at org.openide.loaders.MultiDataObject.handleDelete (MultiDataObject.java:422) at org.openide.loaders.DataObject$3.run (DataObject.java:536) at org.openide.filesystems.EventControl.runAtomicAction (EventControl.java:89) at org.openide.filesystems.FileSystem.runAtomicAction (FileSystem.java:416) at org.openide.loaders.DataObject.delete (DataObject.java:534) at org.openide.loaders.DataNode.destroy (DataNode.java:221) at org.openide.nodes.FilterNode.destroy (FilterNode.java:407) [catch] at org.openide.explorer.ExplorerActions$DeleteActionPerformer$ DestroyAtomic.invoke(ExplorerActions.java:531) at $Proxy4.run(Unknown Source) at org.openide.filesystems.EventControl.runAtomicAction (EventControl.java:89) at org.openide.filesystems.FileSystem.runAtomicAction (FileSystem.java:416) at org.openide.explorer.ExplorerActions$DestroyInvoker.run (ExplorerActions.java:565) at org.openide.explorer.ExplorerActions$DeleteActionPerformer. doDestroy(ExplorerActions.java:506) at org.openide.explorer.ExplorerActions$DeleteActionPerformer. performAction(ExplorerActions.java:476) at org.openide.util.actions.CallbackSystemAction.performAction (CallbackSystemAction.java:108) at org.openide.util.actions.CallableSystemAction.actionPerform ed(CallableSystemAction.java:69) at org.netbeans.core.ModuleActions$1.run (ModuleActions.java:104) at org.openide.util.Task.run(Task.java:136) at org.openide.util.RequestProcessor$Processor.run (RequestProcessor.java:599)
OK, I agree with the waiver then, this does not seem to be too critical problem, and looks like it is not possible to fix or workaround.
The relevant JDK bug mentioned above (the fact that calling JarURLConnection.setUseCaches(false) has no effect) is 4211817. http://developer.java.sun.com/developer/bugParade/bugs/4211 817.html This bug was fixed in JDK 1.3.1_01a and JDK 1.4.0, so we can now ask the Tomcat team to fix the issue in their code. I will investigate the desired changes in the Tomcat code.
Here is some more progress on the bug. I made a change to Tomcat (basically a bugfix), which makes deletion work in the following scenario: 1. open a JSP which uses tag libraries in the editor 2. try to delete one of the tag library jar files in WEB- INF/lib This fix may fix other aspects of this bug (deletion after compilation etc., but I did not try). I am attaching the new TldLocationsCache.java file, the diff, and the new modules/ext/jasper-compiler.jar. I tested this with the S1S 4.1 (Sierra) build. Going forward, there are several approaches we can take. For the S1S 4.1 patches, we can either distribute the modified jasper-compiler.jar (if we are legally allowed to do this), or we can try to port the fix over to our code, which at first sight looks difficult, but possible. For the future releases of NetBeans/S1S, we should definitely try to contribute the patch to the Tomcat team and so it is in Tomcat distribution. I still need to test how this bug affects standalone Tomcat.
Created attachment 7514 [details] New TldLocationsCache.java (Tomcat source)
Created attachment 7515 [details] The diff against Tomcat 4.0.4
Created attachment 7516 [details] The new modules/ext/jasper-compiler.jar for use with S1S 4.1
This won't solve the problem, but it would make things easier for tag library developers at least: Could we do something to avoid mounting the jar file in case it's built from sources that are currently mounted in the IDE? It's a hack but it could help a little until we fix the root cause. Ana
Created attachment 8058 [details] Patch submitted against Tomcat 5 dev.
*** Issue 30336 has been marked as a duplicate of this issue. ***
*** Issue 30472 has been marked as a duplicate of this issue. ***
*** Issue 30710 has been marked as a duplicate of this issue. ***
Some time ago, I filed a bug 19219 against Tomcat, which is probably the root cause of the problem. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19219 This bug is now fixed in Tomcat 5.0.3, so we should incorporate 5.0.3 to NetBeans so we can find out whether the fix worked.
Another user has the same problem: http://www.netbeans.org/servlets/ReadMsg?msgId=535940&listName=nbusers Stack trace: ------------- org.netbeans.modules.javacvs.JavaCvsFileSystemException: File could not be deleted. at org.netbeans.modules.javacvs.JavaCvsFileSystem$ChangeImpl.delete(JavaCvsFileSystem.java:1207) at org.openide.filesystems.AbstractFileObject.delete(AbstractFileObject.java:494) at org.openide.loaders.FileEntry.delete(FileEntry.java:100)
I have the same problem with servlets, so it's not related to JSP. Here is the stack trace in NetBeans 3.5 (Windows 2000): org.openide.filesystems.FSException: Cannot delete file WEB-INF/classes/fr/alma/scenario/Play.class in E:\scenario. at org.openide.filesystems.FSException.io(FSException.java:91) at org.openide.filesystems.LocalFileSystem.delete(LocalFileSystem.java:236) at org.netbeans.core.ExLocalFileSystem.delete(ExLocalFileSystem.java:75) at org.openide.filesystems.LocalFileSystem$Impl.delete(LocalFileSystem.java:478) at org.openide.filesystems.AbstractFileObject.delete(AbstractFileObject.java:494) at org.openide.filesystems.MultiFileObject.needsMask(MultiFileObject.java:1339) at org.openide.filesystems.MultiFileObject.delete(MultiFileObject.java:1082) at org.netbeans.modules.java.CleanCompiler.deleteClasses(CleanCompiler.java:134) at org.netbeans.modules.java.CleanCompiler.compile(CleanCompiler.java:174) at org.netbeans.modules.java.CleanCompilerGroup$1.run(CleanCompilerGroup.java:82) at org.openide.filesystems.EventControl.runAtomicAction(EventControl.java:89) at org.openide.filesystems.FileSystem.runAtomicAction(FileSystem.java:414) at org.netbeans.modules.java.CleanCompilerGroup.start(CleanCompilerGroup.java:109) at org.netbeans.core.compiler.CompilationEngineImpl$CompilerThread$GroupCompiler.run(CompilationEngineImpl.java:280) Errors compiling fr.
There is some hope that bugfix for issue 36617 and issue 20743 in JarFileSystem has improved this behavior. Now JarFileSystem does not hold the jar file open for a long time. Need to verify in trunk.
This issue is now fixed (please reopen if this is still happening). The fundamental cause of this bug is that JarURLConnection in cached mode is used to read data from jar files in the classloader used by the JSP Parser, and that jar files are not closed after the IDE has finished reading from them. The classloader is owned by the JSP parser module, and then passed to Tomcat code, which then reads classes from it. This problem existed in standalone Tomcat 4, but was fixed in Tomcat 5, by improving Tomcat's classloader and correcting Jasper code that works with jar files. See also Tomcat bug http://issues.apache.org/bugzilla/show_bug.cgi?id=19219. Also, the IDE's treatment of jar files has improved recently, see issue http://www.netbeans.org/issues/show_bug.cgi?id=20743. However, these bugfixes alone did not fix the problem. An additional fix needed to be on our side: improving our classloader so it treats jar files gracefully. So the nature of this fix is to improve the URLClassLoader that is used by the JSP parser to load classes. Instead of jar: URLs, we are supplying nb: URLs to it. The result is that classes are not loaded using JarURLConnection, but using internal IDE connection. We still need to use a small hack, as Tomcat anticipates that jar: URLs are used. So to external clients, the classloader pretends that it is using jar: URLs. Fixed in NetBeans 3.6 codebase.
BTW, the fix is: web/jspparser/src/org/netbeans/modules/web/jspparser/WebAppParseSupport.java, rev. 1.12
v
will note release note for 3.6 but keeping the RELNOTE keyword in case other editions need it.
other editions based on 3.5; e.g. it doesn't look like this change was ported to arrow