Some thoughts on hot deployment support for further discussion (summarizing some thoughts from David, Jason, John, Jesper, all mistakes are my own)
First, terminology: what's being discussed here is hot-deploy in the traditional AS sense of detecting deployment archive changes and redeploying. It's not things like replacing classes in a running application. I assume though we want to support the exploded web archive resource (including jsp file) replacement we've traditionally supported (unless the JBW say otherwise).
Hot deploy support will be limited to the standalone server use case. Hot deployment will not be supported via the Domain Controller; users should use the regular deployment API.
For zipped archives:
Scanner will detect an archive in the hot-deploy dir, e.g. hot-deploy/foo.war. Scanner will use the same deployment API that an external client would use to register the content with the server and deploy it. Once the content is registered the server will maintain it's own copy in an internal directory (e.g. server/data/deployments). Scanner will replace the hot-deploy/foo.war file with a simple marker file hot-deploy/foo.war.deployed.
User can trigger a redeploy of the existing foo.war content by touching hot-deploy/foo.war.deployed.
User can trigger an undeploy of foo.war by deleting hot-deploy/foo.war.deployed.
User can trigger a replacement of foo.war (undeploy old, deploy new) by copying a new foo.war into hot-deploy/
For exploded archives:
User can copy an exploded archive into hot-deploy/ (e.g. hot-deploy/foo.war/) but this will not trigger a deployment.
It will trigger an INFO level message in the log noting that the exploded archive has been detected.
To trigger a deployment user must copy a marker file jboss.deploy to META-INF.
So, user can copy a large deployment without worrying that it will be deployed when only partly copied.
User can trigger a redeploy of the existing foo.war content by touching hot-deploy/foo.war/META-INF/jboss-deploy
User can trigger an undeploy of foo.war by deleting hot-deploy/foo.war/META-INF/jboss-deploy
Undeploy by deleting the entire hot-deploy/foo.war/ directory is not supported! The user should delete hot-deploy/foo.war/META-INF/jboss-deploy to trigger undeploy, after which they can delete the entire directory if they so choose. If they leave the directory, that will not result in risk of another deploy (e.g. after server restart), since the META-INF/jboss-deploy won't be there.
Users can replace content in the exploded archive (e.g. hot-deploy/foo.war/index.html). We need to clarify exactly what the results of this will be; e.g. whether we support the current AS 6 behavior, something more, something less...
If we support something like the AS 6 behavior where some content changes are reflected in the runtime without a redeploy, the Scanner will be responsible to informing the server of the new content. It will do this via a separate internal API, not the regular end-user deployment API. If we end up adding methods needed for updating content without redeploy to the regular end-user deployment API, or to some other end-user API, the scanner should use that API. But we will not add methods to an end-user API solely to support scanner operations.
The current assumption is the scanner will tell the server to mount the exploded archive directly from the hot-deploy dir, rather than copying it. But that is an internal implementation detail subject to change.