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 73993 - Problem with locked jars on Windows
Summary: Problem with locked jars on Windows
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 5.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: issues@java
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-25 17:58 UTC by Kedar Mhaswade
Modified: 2007-09-26 09:14 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
the jar fie with everything in it. (8.14 KB, application/octet-stream)
2006-03-25 18:05 UTC, Kedar Mhaswade
Details
Process Explorer showing the process tree and the handle on a jar (103.18 KB, image/jpeg)
2006-07-06 14:17 UTC, denbo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kedar Mhaswade 2006-03-25 17:58:35 UTC
I am not sure if I selected the correct cateogry. Please redirect as appropriate.
A little prerequisite to reproduce this bug is necessary and I am sorry for
that. This is necessary mainly because I am facing a real problem with this and
I just want to simulate the situation.
- install the latest GlassFish build. This is only so that you can get access to
few large jars on which a project might depend. This is really a quick step.
- explode the attached jar.
- open the project by doing File->Open Project ...
- modify the GlassFish location so that now, this project uses the large jars
from your installation.

Scanning of classpaths starts, and it goes on for few minutes. Once that's done
and mdrstorage is created, all the appserver jars that this project refers to,
are LOCKED. That's it. You can't touch those jars anymore on Windows.

Open the same Project in NB 4.1.
No problem.

Why is this a *huge* problem?
GlassFish has an ant/maven based build that modifies the appserver jars during
the build. This is a way to quickly update the jars and debug your issues. I use
NetBeans to develop/debug. Once I modify the source, I go to command line and do
the maven build of sources I modified.
The build fails as long as the project is open in NetBeans.
Once I close the project, everything is all right.

Again, this does *not* happen with NB 4.1.

This is a definite defect with scanning of classpaths for a project. I am pretty
sure that it is a regression from 4.1. This poses a *huge* problem for me with
my GlassFish build. As you know, GlassFish/NetBeans collaboration is critical
and for that to happen, we have to get this fixed asap.
Comment 1 Kedar Mhaswade 2006-03-25 18:05:50 UTC
Created attachment 29402 [details]
the jar fie with everything in it.
Comment 2 Jesse Glick 2006-03-25 21:30:02 UTC
If it's really a problem with the scanning system, then not a project issue, but
rather javacore. That is speculation at this point though. Generally these
issues can be hard to track down since you need to find the code which opened a
file lock (probably java.util.jar.JarFile in this case) and failed to release
it. The only good way to do that (as far as I know) is to either guess in the
dark; or run a memory profiler, which requires reproducibility.

Do you have some kind of self-contained, reproducible test case that does not
refer to Glassfish or external software? Certainly high priority if this happens
regularly in different contexts, but we don't know that yet.
Comment 3 Kedar Mhaswade 2006-03-25 22:41:15 UTC
Thank you, for looking into it.

Basically, I tried it with a standalone simple jar that has few classes as a
library that I refer to from within my classes in project and I can not
reproduce this. Then I tried to use a few jars that are reasonable in size (from
few KB to few MB) and then I certainly can reproduce this a 100% of the times.

Actually, I first hit this issue with successfully working GlassFish builds. I
was happy that I created a project that contains sources from various CVS
modules and then using these jars to resolve everything. I was happy that all
the red ugly underlines had gone since all the classes were successfully
resolved by the scanning system.

This was with 4.1.
I moved to 5.0 and immediately started seeing this problem.

Ludo asked me to create a standalone case independent of GlassFish build and I
did the same. The only thing I could not isolate was the number and sizes of
jars that I refer to, from within my projects.

The issue should not be hard to reproduce at all. Just download the GlassFish
image from link I provided and then create a freeform project that refers to the
jars from its lib directory. You can pick a handful of them. 

Start the IDE.
Try to do a "move appserv-rt.jar foo.jar"; Windows disallows it since file is
locked.
Comment 4 Jan Becicka 2006-03-31 10:48:13 UTC
Just to be sure, that scanning is the evil, please try to run netbeans with
"-J-Dnetbeans.javacore.noscan=true"
and try the same scenario.

Thanks.
Comment 5 Jan Becicka 2006-05-04 14:39:34 UTC
kmhaswad?
Comment 6 denbo 2006-07-06 14:15:45 UTC
I have the same problem: Netbeans locks my jars so I cannot delete them. 

As suggested, I tried switching off scanning, but it did not make any difference. 
In order to see which process actually owns the lock, I used Process Explorer by
sysinternals.com (see attachment). It is definitely a Netbeans subprocess
holding the lock. If I remove the lock manually I can delete the jars.

The problem occurs even if cleaning is the first thing I do after starting the IDE.

The project I used was a freeform project.

I use: JDK 1.5.0_06
The error message I get from Ant: "Deleting directory
C:\_work\workspace\web3CI\src\web\WEB-INF\lib
C:\_work\workspace\web3CI\buildMWX.xml:331: Unable to delete file
C:\_work\workspace\web3CI\src\web\WEB-INF\lib\commons-collections.jar"

The attachment shows the process tree as displayed by Process Explorer and the
handle the java process holds on the file I wanted to delete.
Comment 7 denbo 2006-07-06 14:17:37 UTC
Created attachment 31671 [details]
Process Explorer showing the process tree and the handle on a jar
Comment 8 Kedar Mhaswade 2006-07-06 17:03:55 UTC
My problem is a little different than that of denbo's. Though this bug is in
incomplete state, I think there is something wrong. I will try it out on some
other Windows box and revalidate my findings. 

Someone told me (Vince, Sreeram) that in my particular case, the NetBeans IDE holds
locks to my GlassFish library jars if any of the GlassFish domains is registered
in the IDE as a target server. But I am not sure that that's right. Anyway, I will
confirm this soon.

Thanks (denbo) for adding your comments to this bug.
Comment 9 Jan Becicka 2006-10-26 16:27:14 UTC
Javacore module was replaced by Retouche infrastructure. This bug is not valid
in trunk any more.
Comment 10 Quality Engineering 2007-09-20 12:31:33 UTC
Reorganization of java component