I've seen this problem also, put sporadical.
What about using the war as archive instead of exploded deployment?
In this case it will be hotdeployable for me.
your problem occurs due to the windows "Indexing service".
On Windows 2003 Server, just go to Start->Programs->Administrative Tools and select "Services".
You should see the management console for Services. In the list of services, point to "Indexing Service" and turn that off for now and ever.
Maybe you have to restart your server.
We still have this very annoying problem in final JBoss AS6 and Eclipse Indigo last release. Once deployed all jars in WEB-INF/lib are locked, even after removing WAR and EAR. Only jboss restart allows to remove the fles in deploy directory. Full deploy is then impossible after first deployment, as we have now each time an Eclipse error msg like : Error renaming C:\jboss6\server\default\tmp\jbosstoolsTemp\tmp1686423259759383303.jar to C:\jboss6\server\default\deploy\FluideMe.war\WEB-INF\lib\commons-beanutils.jar.
We cannot move those jars out of WEB-INF/lib folder because if we do so, then we have classloaders issues when we deploy in target production environnement where our WAR is not packaged with the core EAR.
Any help ?
As I said before for me the problem was sporadic but I use no WAR deployment. What about the tip of Christoph Hirte to stop the indexing service?
I read about a 'unlocking tool' for windows but I suppose that is not that what you (and me too) want.
Do you deploy the WAR exploded? If yes you might check as a file deployment.
I agree that this will be a annoying problem but it is only under Windows, now I use Linux as platform and there is no problem like this
Finally we got out this problem by a workaround. Note first that removing indexing service completly didn't solve at all the issue. What we did is the following : for application specific jar required by our EAR projet we put them is server/default/lib. For the WARs managing JSF projects we put then in a dedicated configuration for JSF, as indicated here.
Once this done we don't have anymore jars in WEB-INF/lib project subdirectories. As the locking issues were only related to those jars, the problem is solved. We also saved a bit of deployement time over the network, as transfering those jars was taking quite a long time.
It remains quite surprising that most posts and documentation about JBoss deployement always refer to using WEB-INF/lib while there is a very good solution to not using this for jars that are never or almost never updgraded.
Note also that deploying as a packaged EAR or WAR also solves the problem, but it is not an acceptable solution in development phase, because then you cannot use incremental publish which is very practical when you tune JSF pages for example.