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.
steps to reproduce: 1) create Web project with Visual Java Server Faces 2) run project 3) rename project (with renaming the directory as well) via the context menu Product Version: NetBeans IDE Dev (Build 070810) 'FULL IDE' Java: 1.6.0_02; Java HotSpot(TM) Client VM 1.6.0_02-b06 System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb) GlassFish V2 build b58-rc1
Created attachment 46451 [details] stacktrace
yup. since the app is in use... the jar is in use... work-around? stop the server before doing the rename operation. (that will lead to other issues when the server restarts... since the app is GONE) We may be able to add some listener on directory deployed projects... that would track the rename/delete operations.. but that is a future thing.
same for tomcat....
change summary from "cannot delete prototype.1.5.0.jar"
since this spans server plugins, the solution would probably need to get implemented primarily in the j2eeserver module.
*** Issue 115952 has been marked as a duplicate of this issue. ***
change summary from "Rename project (and directory) of running web app fails on Windows"
The correct solution is to call undeploy before clean. However this works only when the jars are _not_ locked due to ClassLoader.getResource(). Tomcat for instance handle it by the webapp classloader property configurable in context.xml (antiJARLocking). I don't know about any such solution for the glassfish (although it suffer from the same locking issues, see links below). I'm not sure this can be handled at all (without some risky bootstrap classloader settings). I will investigate it further. http://tomcat.apache.org/faq/windows.html#lock http://blogs.sun.com/quinn/entry/addressing_locked_jar_problems
Calling undeploy before clean could be solved by patch for the following enhancement issue 83122. However the jar locking issue will not be fixed by it (in general).
It would need a support of app server. There could be done some partial (enhancement issue 83122) solution for 6.0.
This is also adressed by request for enhancement on jdk: http://bugs.sun.com/view_bug.do?bug_id=4950148
The current problem for visual jsf is caused by the woodstock project using the sun.misc.Service. I filed the issue: https://woodstock.dev.java.net/issues/show_bug.cgi?id=812
*** Issue 92021 has been marked as a duplicate of this issue. ***
*** Issue 123777 has been marked as a duplicate of this issue. ***
The impact of the issue should be lower after this jdk bug will be fixed: http://bugs.sun.com/view_bug.do?bug_id=6587593 This should happen for jdk6u10.
*** Issue 136235 has been marked as a duplicate of this issue. ***
Issue 83122 contains the patch I would like to apply after some additional testing. It should solve this issue. The possible drawback is undeploy on each clean. There is now way (afaik) how to figure out whether app was deployed from a directory or in a standard way.
Should be fixed by undeploy on clean. Fixed in main 5d7eec56a42d.
Integrated into 'main-golden', will be available in build *200809151401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/5d7eec56a42d User: phejl@netbeans.org Log: #112529 Clean target on running web app fails on Windows (undeploy performed on clean)