[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-18862: --------------------------------------------- Darryll - we already do all the stuff you are saying...what we have now is a bug in this implementation that was missing the case where .dodeploy was possible to be present if you don't start the server before first publish occurs. That will be fixed; and that is what Rob is suggesting he fix. Btw. rob - we should fix this in 4.2.x too. To comment on Daryll steps: {{{ Step 1) Eclipse instructs the AS to inhibit all deployment operations! }}} Since AS7/WildFly do *not* start deploying things before there actually is a .dodeploy or the last byte of an archive file is available this is already in place (sans the missing removal of .dodeploy in the special case) For pre-AS7 and the cases where jmx/api is enabled/availble we tell the server to stop autoscanning for deployments. {{{ Step 2) The AS positively acknowledges this instruction from Step 1 above (in the case of a deployment is in progress at the AS side, it would not need to be aborted, it would continue until success or failure, at that point the AS would return the positive acknowledgement that all AS deployment operations have been temporary inhibited at Eclipse's request). }}} If we had to wait for this smallest updates would be slow. There is no need for this when Step 1 is done properly - which it is. {{{ Step 3) Eclipse does publish operation (modifies files/dirs). }}} Yup. {{{ Step 4) Eclipse instructs the AS the remove the inhibit of all deployment operations. Ideally this might be done with remoting/EJBclient/HTTPwebsocket so if the socket connection breaks/closes that also removes the inhibiter at the AS side. }}} I do not know what this means. But my guess is you mean the server should not start deploying before we are done copying. This happens today via .dodeploy marker or by using management operations or by the archive being fully copied. It is not an inhibitor it is an *activator*. {{{ Step 5) This also allows the AS to immediately deploy what is sees. No waiting around a few seconds for something to notice. Although I've not seen this problem in a while. }}} Yes, because that is what AS7/WF8 the jboss tools do. Note, if you use <Java7 there is a 5 second delay by default to not slow other things down, >Java7 native java file monitoring hooks are used. As Rob said - making sure .dodeploy file is removed before we deploy anything no matter if incremental and/or full is what is missing to cover all bases afaics. -- This message was sent by Atlassian JIRA (v6.3.8#6338)