[jbosstools-issues] [JBoss JIRA] Commented: (JBIDE-4608) Hot deployment woks incorrectly with JBossAS Tools

[ https://jira.jboss.org/jira/browse/JBIDE-4608?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-4608: ------------------------------------ Interesting. Because you're using all JEE code (as opposed to J2EE) you have no descriptors. The way we used to ensure restart of a module was by touching the descriptors. Since there aren't any, this isn't happening. Simply changing byte code does not tell the jboss AS to re-scan the folder for changes (no hot-deploy there on a runtime level so nothing the tooling can do). This is being tested on the JBoss 5.0.x stream. JBoss 5.0.x does *not* have JMX suspend / resume deployment scanner, so that's not an issue here and cannot be complicating the matter. As you mentioned, doing a full publish does not cause the runtime to republish. Not only has the changed class been modified (which should not honestly restart the app on the server), but the entire ear folder was removed and a new one coppied in with a new timestamp. [rob@localhost deploy]$ ls -l | grep "clear" drwxrwxr-x 3 rob rob 4096 2009-07-14 14:06 clear-ear.ear :: perform full publish inside eclipse :: [rob@localhost deploy]$ ls -l | grep "clear" drwxrwxr-x 3 rob rob 4096 2009-07-14 14:09 clear-ear.ear So the timestamp of both the folder and all files changes, but the underlying JBoss AS runtime does not redeploy the application. I feel this is a problem with the runtime and not hte tooling. For completeness, the file tree of this application is as follows: [rob@localhost deploy]$ du -a clear-ear.ear/ 8 clear-ear.ear/clear-ejb.jar/EJBRem.class 8 clear-ear.ear/clear-ejb.jar/EJB01.class 8 clear-ear.ear/clear-ejb.jar/META-INF/MANIFEST.MF 16 clear-ear.ear/clear-ejb.jar/META-INF 8 clear-ear.ear/clear-ejb.jar/jndi.properties 8 clear-ear.ear/clear-ejb.jar/EJBTest.class 56 clear-ear.ear/clear-ejb.jar 64 clear-ear.ear/ Effectively, the entire clear-ear.ear folder is removed and a new one put in its place with a new timestamp, however possibly very quickly. It seems the deployment scanner does not recognize this redeployment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira