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.

Bug 20384 - MOD: FSException: Cannot delete WEB-INF/lib/jar file
Summary: MOD: FSException: Cannot delete WEB-INF/lib/jar file
Status: VERIFIED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Code (show other bugs)
Version: -FFJ-
Hardware: PC Windows ME/2000
: P2 blocker with 1 vote (vote)
Assignee: Petr Jiricka
URL:
Keywords: RELNOTE
: 20877 24057 24398 30336 30472 30710 (view as bug list)
Depends on: 36617
Blocks:
  Show dependency tree
 
Reported: 2002-02-08 18:45 UTC by _ hlu
Modified: 2010-01-12 02:04 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
web module (3.54 KB, application/octet-stream)
2002-03-05 19:16 UTC, _ hlu
Details
New TldLocationsCache.java (Tomcat source) (12.70 KB, text/plain)
2002-09-25 18:38 UTC, Petr Jiricka
Details
The diff against Tomcat 4.0.4 (2.85 KB, patch)
2002-09-25 18:39 UTC, Petr Jiricka
Details | Diff
The new modules/ext/jasper-compiler.jar for use with S1S 4.1 (208.45 KB, application/octet-stream)
2002-09-25 18:41 UTC, Petr Jiricka
Details
Patch submitted against Tomcat 5 dev. (4.36 KB, patch)
2002-11-26 15:09 UTC, Petr Jiricka
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description _ hlu 2002-02-08 18:45:40 UTC
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)
Comment 1 _ hlu 2002-03-05 19:13:01 UTC
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)

Comment 2 _ hlu 2002-03-05 19:14:30 UTC
Change P5->P2.
Comment 3 _ hlu 2002-03-05 19:16:59 UTC
Created attachment 4949 [details]
web module
Comment 4 sgleason 2002-03-05 19:27:01 UTC
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.
Comment 5 sgleason 2002-03-06 02:32:43 UTC
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. 


Comment 6 sgleason 2002-03-14 00:03:52 UTC
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. 
                        
                        
Comment 7 sgleason 2002-03-14 00:04:39 UTC
*** Issue 20877 has been marked as a duplicate of this issue. ***
Comment 8 sgleason 2002-04-08 16:56:55 UTC
Waiving this one for FFJ 4.0, per iteam decision. 
Comment 9 Jan Chalupa 2002-05-02 10:49:15 UTC
Waiver approved.
Comment 10 sgleason 2002-05-30 18:22:45 UTC
*** Issue 24057 has been marked as a duplicate of this issue. ***
Comment 11 Petr Jiricka 2002-06-05 08:41:48 UTC
*** Issue 24398 has been marked as a duplicate of this issue. ***
Comment 12 Marek Grummich 2002-07-22 12:02:35 UTC
Set target milestone to TBD
Comment 13 Marek Grummich 2002-07-22 12:06:03 UTC
Set target milestone to TBD
Comment 14 Petr Jiricka 2002-07-30 17:47:18 UTC
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.
Comment 15 iformanek 2002-07-30 17:52:26 UTC
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.
Comment 16 Patrick Keegan 2002-07-30 21:56:20 UTC
approved waiver; keep my name in cc for release note purposes
Comment 17 Petr Jiricka 2002-08-01 16:57:00 UTC
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)
Comment 18 iformanek 2002-08-01 17:53:22 UTC
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. 
Comment 19 Petr Jiricka 2002-09-05 07:42:40 UTC
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.
Comment 20 Petr Jiricka 2002-09-25 18:37:11 UTC
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.
Comment 21 Petr Jiricka 2002-09-25 18:38:41 UTC
Created attachment 7514 [details]
New TldLocationsCache.java (Tomcat source)
Comment 22 Petr Jiricka 2002-09-25 18:39:39 UTC
Created attachment 7515 [details]
The diff against Tomcat 4.0.4
Comment 23 Petr Jiricka 2002-09-25 18:41:25 UTC
Created attachment 7516 [details]
The new modules/ext/jasper-compiler.jar for use with S1S 4.1
Comment 24 Ana.von Klopp 2002-09-27 18:58:11 UTC
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
Comment 25 Petr Jiricka 2002-11-26 15:09:51 UTC
Created attachment 8058 [details]
Patch submitted against Tomcat 5 dev.
Comment 26 Petr Jiricka 2003-01-27 09:41:12 UTC
*** Issue 30336 has been marked as a duplicate of this issue. ***
Comment 27 sgleason 2003-03-01 00:00:14 UTC
*** Issue 30472 has been marked as a duplicate of this issue. ***
Comment 28 psuk 2003-03-11 09:52:22 UTC
*** Issue 30710 has been marked as a duplicate of this issue. ***
Comment 29 Petr Jiricka 2003-06-25 10:57:30 UTC
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.

Comment 30 psuk 2003-07-03 13:29:46 UTC
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)
Comment 31 pgodeau 2003-11-17 16:53:51 UTC
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.
Comment 32 Petr Jiricka 2003-11-24 08:52:50 UTC
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.
Comment 33 Petr Jiricka 2004-01-27 14:26:33 UTC
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.
Comment 34 Petr Jiricka 2004-01-28 08:36:28 UTC
BTW, the fix is:

web/jspparser/src/org/netbeans/modules/web/jspparser/WebAppParseSupport.java,
 rev. 1.12
Comment 35 Martin Schovanek 2004-03-02 10:45:44 UTC
v
Comment 36 Patrick Keegan 2004-03-03 21:31:52 UTC
will note release note for 3.6 but keeping the RELNOTE keyword in case
other editions need it.
Comment 37 Patrick Keegan 2004-03-04 19:02:08 UTC
other editions based on 3.5; e.g. it doesn't look like this change was
ported to arrow