Nice! :)
Here's some questions I have:
Brian Stansberry wrote:
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.
Would it be a "rename" or would the foo.war.deployed be a completely different file? From what I understand, I believe it would be a completely different file without any .war semantics, but just wanted to be sure. Furthermore, where would be original foo.war be moved to? Are users expected to know where it's moved to? If not, then they probably will have to maintain a copy of their original deployment somewhere (I know most of them already do that, but again I just wanted to be clear about the expectations).
Brian Stansberry wrote:
User can trigger a replacement of foo.war (undeploy old, deploy new) by copying a new foo.war into hot-deploy/
Later in your post, I see that special care has to taken to avoid spurious hot deploys (i.e. picking up a deployment even before it is completely copied to hot-deploy folder) for exploded deployments. How do we handle such cases for these zipped archives? i.e. What happens when a zipped foo.war is still being copied to hot-deploy and the scanner picks it up for deployment?
Brian Stansberry wrote:
For exploded archives:
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.
Any specific reason why deleting the hot-deploy/foo.war directory shouldn't undeploy the application? If foo.war is deleted it effectively means foo.war/META-INF/jboss.deploy too is deleted, so I'm not sure why we can't support it. I guess there's something I'm missing :)
In addition to the above, I can think of a few more cases:
"Leaf" deployments:
What do we plan to do with "leaf" file hot-deployments? For example, consider a hot-deploy/mail-service.xml (I know for AS-7, *-service.xml may not be relevant, but let's consider it just as an example). How is hot deployment handled for such files? Or for that matter, how is deployment handled for such "leaf" files in the hot-deploy folder? Would it too create a mail-service.xml.deployed marker? Do we plan to (somehow) avoid spurious hot deploys for such files?
Nested deployments:
In case of nested deployments, I believe only the top level META-INF/jboss.deploy marker file plays a role. Any marker files in sub-deployments of the top-level deployment, will not have any effect on the hot-deploy semantics. Am I right?
Finally, are the *.deployed and jboss.deploy marker file semantics only specific to a hot deployment enabled folder (like hot-deploy)? Considering a simple foo.war zipped archive in a normal deploy folder (without hot deployment), would it too be replaced with a marker foo.war.deployed file? And would jboss.deploy play a role in exploded deployment in a normal deploy folder?