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.
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)
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.
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.
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.
I think that this issue should have been resolved by web apps people with possibly different resolution than WONTFIX. Reassigning, reopening, raising prio.
Hi, thanks for the report - you are not the only one who encountered this!
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.
*** Issue 49533 has been marked as a duplicate of this issue. ***
*** Issue 48890 has been marked as a duplicate of this issue. ***
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.
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).
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.
*** Issue 48736 has been marked as a duplicate of this issue. ***
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
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
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).
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?
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.
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.
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>
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.
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?
Marking as fixed in 4.0, I do not plan to implement automatic undeploy (not a priority and not a bug).
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?
v
*** Bug 48736 has been marked as a duplicate of this bug. ***