jaikiran pai wrote:
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 meant a different file, and they shouldn't necessarily be poking in the data area, which I admit is not intuitive. That's a very good point. It's also inconsistent with the exploded dir, which preserves the original. We could alternatively leave the file there and just add the .deployed as an indicator that it was deployed. The only side effect is that it would require a copy vs a move, but IMO not a huge deal for zips.
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?
What I had in my head for that scenario, was that we would just detect an incomplete zip, and wait for the next few intervals before reporting the failure. It's pretty easy to do this because zip files store the directory at the end.
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?
Correct. We would basically treat the outer deployment as an atomic entity, and only look for the markers relevant to it.