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.
When deploying web apps into the embedded Tomcat, sometimes attempts to reploy fail with an error that reports that a file necessary to rebuild the WAR file is not accessible. The only solution seems to be to quit NetBeans (and so also Tomcat), then restart. Tomcat 5.5. has a solution for this: webs apps on Windows ought to add 'antiResourceLocking="true"' as an option to their Context (in context.xml). Perhaps NetBeans should add this option to that file by default.
This is not a real P2, changing the priority to P3. I guess this problem occurs only if you run clean & build, right? Running only build might pass. We will think about adding the antiResourceLocking="true" to the context.xml file by default. It is, however, to late for this changes in NB5.5. TM -> Dev
Sorry - I was not sure what the difference was between P2 and P3. But this made developing and testing under this config (deploying to embedded tomcat) nearly unusable. I don't think 'clean' is necessary for the issue to crop up. In my case, all I needed to do was deploy the application twice in a row, assuming it was not originally deployed to the embedded Tomcat. The first deploy would suceed - the second would abort when attempting to rebuild the WAR file due to a locked file. I don't think the deploy task cleans by default...
BTW, you can disable generating the war file by unchecking the "Create War File" checkbox in the Project Properties > Build > Packaging dialog. Can you describe a little bit your web app? I mean what frameworks do you use (e.g. hibernate, log4j...) ?
Ah! Unchecking "Create WAR file" also works as a workaround! With it, I am happy with P3 for this issue :-). The list of libraries my web app uses: Struts 1.2.7, Jakarta (Commons httpclient 3.0.1, codec 1.3, fileupload 1.1.1, io 1.2), POI 2.5.1, JSTL, JTA spec 1.0.1. (A first attempt to use jotm did not work, and I backed it out until I have time to tinker with it again...). A simple test webapp that only includes Struts did not have this issue.
Speaking of which - the build target can fail, when deploying onto an embedded Tomcat. In my case, my app creates log files inside WEB-INF - and these are held open by tomcat and so cannot be deleted by the clean target...
*** Issue 87476 has been marked as a duplicate of this issue. ***
Adding antiResourceLocking="true" to context.xml does not seem to be what we want, since it would disable JSP reloading in a running server, see http://issues.apache.org/bugzilla/show_bug.cgi?id=37668. In NB 6.0 the "Create War File" check box is unchecked by default, so this issue is most likely not gonna occur anymore. Closing the issue as WONTFIX.