Bug 47919 - Project Clean and Build can't delete jar file because it is in use.
Project Clean and Build can't delete jar file because it is in use.
Status: VERIFIED FIXED
Product: javaee
Classification: Unclassified
Component: Web Project
4.x
PC Windows ME/2000
: P3 (vote)
: 4.x
Assigned To: Pavel Buzek
issues@javaee
:
: 48736 48890 49533 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-25 15:03 UTC by rwynkoop
Modified: 2015-10-26 17:16 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rwynkoop 2004-08-25 15:03:08 UTC
I was debugging.  Had debugger stopped.  Tried to
do a Project clean and build.  Needs to prompt to
stop server.

Build Message:  (Paths edited down.)
C:\nbproject\build-impl.xml:381: Unable to delete
file C:\build\web\WEB-INF\lib\activation.jar
BUILD FAILED (total time: 1 second)
Comment 1 Jesse Glick 2004-08-25 19:02:18 UTC
On Windows, if a JAR file is in use, it is impossible to delete it.
You have to release the lock, e.g. by closing a process using it. Unix
systems permit the file to be deleted - though any subsequent attempt
to use it might cause errors.
Comment 2 rwynkoop 2004-08-27 00:12:43 UTC
Yes, that is correct.  Windows does not let one delete the file. 

So why not have Netbeans shut down Tomcat first then do the clean & 
build.

Comment 3 Jesse Glick 2004-08-27 02:53:22 UTC
Sorry, the Tomcat integration is handled by a totally different part
of the code. Would be rather complex to get that to work at all, much
less reliably.
Comment 4 Milan Kubec 2004-09-21 14:34:19 UTC
I think that this issue should have been resolved by web apps people
with possibly different resolution than WONTFIX. Reassigning,
reopening, raising prio.
Comment 5 Petr Jiricka 2004-09-21 15:25:49 UTC
Hi, thanks for the report - you are not the only one who encountered this!
Comment 6 Pavel Buzek 2004-09-25 00:53:30 UTC
I think the right solution would be to undeploy the module first if it
was deployed. Bad thing is we probably cannot do this automatically -
or can we? If you never deployed the module or even do not have the
server started you do not want to slow down the clean (even just by
testing _is_server_running_ and _is_module_deployed_ - the first one
takes 3 seconds and cannot be speedup by any simple fix, while clean
can be done in an instant). Not speaking of chances that the clean
fails for some problem with undeployment.

Of course it would be possible to add a check box (project property) -
yes, another one - saying "undeploy before clean" and provide an
undeploy task in build script that can also be used by adventurous
users who choose to customize the build script. 

Comment 7 Pavel Buzek 2004-09-25 00:57:21 UTC
*** Issue 49533 has been marked as a duplicate of this issue. ***
Comment 8 Sherold Dev 2004-09-27 10:30:14 UTC
*** Issue 48890 has been marked as a duplicate of this issue. ***
Comment 9 _ gtzabari 2004-09-27 14:00:15 UTC
Pavel,

Restarting Netbeans (due to locked JAR files) is slower than
undeploying the webapp. As for detecting whether the server is up: if
it is the built-in server Netbeans should know whether it was recently
started or not. It is possible that Netbeans will think it is running
but it is really offline, but the opposite case should never happen.
Comment 10 Pavel Buzek 2004-09-27 16:33:05 UTC
The oposite case is in fact what costs us the 3 seconds ;-)
The server can be started by the user from outside of the IDE. This is
true even for bundled tomcat but more likely for an external tomcat.
That's why we do not rely on the information if the server was started
from IDE, we try to detect it (see the Start/Stop action on server node).
Comment 11 zikmund 2004-09-27 16:50:48 UTC
Adding fix-in-40 status whiteboard.
I like the "undeploy before clean" check box solution.

We could also try to do this undeploy only in case that the clean
failed -- if there is a chance of error handling in ant.
Comment 12 Sherold Dev 2004-10-01 10:11:18 UTC
*** Issue 48736 has been marked as a duplicate of this issue. ***
Comment 13 Pavel Buzek 2004-10-11 20:51:05 UTC
ok, thanks for a good suggestion, Karle. 
This is what I am going to try:

First, use failonerror=false in clean:

<target name="do-clean" depends="init">
<delete dir="${build.dir}" failonerror="false"/>
<delete dir="${dist.dir}"/>
</target>

Second, test if everything was deleted:

<available file="${build.dir}" type="dir" property="status.clean-sucess"/>

and if not then display message and try to undeploy:

<target name="-check-clean" if="clean.check" unless="status.clean-sucess">
 <echo message="Build directory: ${build.dir} cannot be deleted. This
may be caused by deployed module files locked by the server. Trying to
undeploy the module." />
 <nbdeploy undeploy="true" clientUrlPart="${client.urlPart}"/>
 <delete dir="${build.dir}"/>
</target>

..the undeploy option needs to be added to nbdeploy task
Comment 14 Pavel Buzek 2004-10-12 18:16:18 UTC
The undeploy code is more complex then I expected (since it was never
supported in API and the deploy code goes thru several layers of
implementation classes). It may be risky to put into 4.0 at this
stage, especially considering the number of changes that was needed in
the deploy code to make it work. 

I've done a partial fix - display an explanatory message when build
directory cannot be deleted. Not sure if I should make the build fail
after displaying this message (as of now it does not fail).

Remove the fix-in-40 if you agree this is enough for 4.0 and the fix
can be completed later.

Checking in src/org/netbeans/modules/web/project/resources/build-impl.xsl;
/cvs/web/project/src/org/netbeans/modules/web/project/resources/build-impl.xsl,v
 <--  build-impl.xsl
new revision: 1.40; previous revision: 1.39
done
Comment 15 zikmund 2004-10-12 18:46:26 UTC
Are we able to delete all files except those in WEB-INF/lib? In such
case I agree with no failing the build. In other case clean&build
should fail.

Is there any possibility to add Undeploy action to pop-up menu of
WebApp project? It is quite annoying to go to Runtime tab and undeploy
web module everytime it happens.

BTW could we check if the JAR files have changed? If they have changed
(typically while developing a library) we should warn user that s/he
should undeploy, if they haven't (typically a library like JSF/Struts)
we should silently build the rest (probably only with a note).
Comment 16 Petr Jiricka 2004-10-13 07:39:58 UTC
BTW, could this be related to the following Tomcat issue?

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29526

It was fixed in Tomcat 5.0.29. Robert and Karel, could we try this
scenario with an external Tomcat 5.0.29, to see whether that will
resolve the problem?
Comment 17 zikmund 2004-10-14 13:58:10 UTC
Still reproducible with Tomcat 5.0.29.
My repro case is:
1) Have WebApp with index.html (no JSP, java) with JSTL added
2) Run
3) wait until page reloads in browser
4) Clean and build
5) Random fail of clean

If you wait in step 3 only 5 seconds you have more than 50% chance
that clean will fail. After the fail it takes usually more than 1
minute than it is possible to do successful Clean -- that's very bad.
Comment 18 Pavel Buzek 2004-10-14 18:04:05 UTC
Karle, all files that are not locked are deleted, the files that
cannot be deleted are listed. You should be able to see and test this
- if you are not let me know.

as for the other question
> BTW could we check if the JAR files have changed?

The files that are up to date are not modified by Ant when doing BUILD
and I think this is enough. When doing clean I would not go into any
such heuristics. For example, it may happen that the user has removed
the jar from project classpath and it should really be deleted even if
it has not changed. You see the point? I think there can be other ugly
cases so clean should mean clean.
Comment 19 zikmund 2004-10-18 14:49:28 UTC
You're right Pavle.

Anyway I did some more tests and discovered this: Tomcat locks the
JARs but it only prevents other processes to delete them. They can be
rewritten!
Therefore I suggest this solution:
Do not show all "Unable to delete file ..." warnings in ant output for
deleting WEB-INF/lib/**/* files (they only confuse the users). Show
just 1 warning for all of them (to cover the case that user has
removed JAR from runtime classpath) + modify behavior of 'copyfiles'
task to fail in cases that the file can't be rewritten (see issue
50559) which will cover the cases when other processes than Tomcat
locked a file in WEB-INF/lib and prevented its rewriting.

Proposed Ant target modifications:
<target name="-do-clean" depends="init" description="...">
   <delete includeEmptyDirs="true" quiet="true">
      <fileset dir="${build.web.dir}/WEB-INF/lib"/>
   </delete>
   <delete includeEmptyDirs="true">
      <fileset dir=".">
         <include name="${build.dir}/**"/>
         <exclude name="${build.web.dir}/WEB-INF/lib/**"/>
      </fileset>
   </delete>
   <available file="${build.web.dir}/WEB-INF/lib" type="dir"              
              property="status.clean-lib-failed"/>
   <delete dir="${dist.dir}"/>
</target>
<target name="-check-clean" depends="-b-do-clean"
        if="status.clean-lib-failed">
   <echo message="Warning: unable to delete some files in WEB-INF/lib
       - they are probably locked by web server which allows their
       rewriting."/>
   <echo message="If you deleted some WEB-INF/lib content you should
       try to undeploy the module from Server Registry in Runtime tab
       and/or Clean again later."/>
</target>
Comment 20 Pavel Buzek 2004-10-18 23:01:10 UTC
Karle, I integrated the patch (thanks!).

Checking in org/netbeans/modules/web/project/resources/build-impl.xsl;
/cvs/web/project/src/org/netbeans/modules/web/project/resources/build-impl.xsl,v
 <--  build-impl.xsl
new revision: 1.43; previous revision: 1.42
done

I did understand your comment that rewritting the jar files works and
only delete fails but I did not put in the last echo message because I
think it would be too cumbersome for the user to understand. IMO we
would ask the user to understand the problems of ide+tomcat too deeply
if we were going to explain why in some situation he/she can ignore
the warning and sometimes not. And it would be too much text to
explain this properly. If you feel very strongly about this pls ask
doc writters for review and I will change the message with their
approval. Perhaps we could also put some info about this into help.

I am removing fix-in-40. and leaving issue open to implement the
automatic undeploying in future.
Comment 21 zikmund 2004-10-19 11:16:51 UTC
Pavle, I found your message wording better than my proposal.

I agree that it's good idea to add a comment to FAQ, troubleshooting
section, etc. with better explanation. Geertjan what do you think?
Comment 22 Pavel Buzek 2005-02-22 18:10:07 UTC
Marking as fixed in 4.0, I do not plan to implement automatic undeploy
(not a priority and not a bug).
Comment 23 Rich Unger 2006-08-08 00:25:17 UTC
It looks like there's a more basic fix in tomcat 5.5.  At
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html there's an attribute
called antiResourceLocking.

Might it be worth re-opening this and changing the internal tomcat's
conf/context.xml?
Comment 24 Dan Kolar 2007-08-06 13:01:20 UTC
v
Comment 25 _ gtzabari 2015-10-26 17:16:00 UTC
*** Bug 48736 has been marked as a duplicate of this bug. ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo