Yes, file locking has been a problem on Windows even in earlier versions of JBoss. My understanding was that it was fixed in AS-5 with the introduction of VFS, but it's still present.
So coming back to your issue - i guess instead of deploying as an exploded folder, you can probably deploy it as archived deployment so that the archive is then extracted into a temp folder by the server and the file-in-use issue will probably be solved. However this has its own disadvantages because, you can't do dynamic changes to files like .jsp without redeploying the application.
I remember that in 5.1.0 version of AS, even exploded deployments were temped (i.e. copied over to temp folder). Could you try 5.1.0 and see if that solves the issue?
I tried both of your suggestions. Switching to 5.1 may not be an option anyways but I tried anyways. I still get the file lock. As for deploying the EAR still archived (not exploded)...well...it solves the issue. At least I can drop it into the deploy folder and jboss deploys it. But it deploys with an error,
[STDOUT] [ERROR] [15 Oct 2009 07:55:40,853] [HDScanner] [MessageFactory ] Could not load message directory: messages. Then I can hit the home page login screen. but when I actually try to log in I get the following error.
07:52:47,039 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception java.lang.NullPointerException at com.paladindata.framework.db.hibernate.HibernateUtil.getTypeClass(HibernateUtil.java:438) at com.paladindata.framework.db.hibernate.QueryBuilder.addField(QueryBuilder.java:864) at com.paladindata.framework.db.hibernate.QueryBuilder.createQuery(QueryBuilder.java:325) at com.paladindata.framework.db.hibernate.HibernateObjectDaoImpl.fetchArray(HibernateObjectDaoImpl.java:338) at com.paladindata.framework.model.AbstractService.getPropertyList(AbstractService.java:178) at com.paladindata.asm.model.user.UserService.login(UserService.java:528) at com.paladindata.asm.web.FormAuthenticationFilter.processLogin(FormAuthenticationFilter.java:442) at com.paladindata.asm.web.FormAuthenticationFilter.doFilter(FormAuthenticationFilter.java:311) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595)
I understand this is in my code but what I don't understand is why I'm getting this error when I try to deploy an archived EAR but not an Exploded EAR. Any ideas?
Ignore that last post...it's a personal issue. ;) Has to do with paths and such that we use in our project and prevents our code from being deployed as archived EARs. Oh well. Unless there's a way around this stupid file locking problem in windows...I suppose there's always linux. :^)
Unless there's a way around this stupid file locking problem in windows...I suppose there's always linux. :^)
I can't find the JIRA which addressed this issue in the upcoming AS 5.2 Beta1. But since you mentioned that upgrading is not an option for you, i think *nix is your only option to get over this issue.