Jason Greene [
http://community.jboss.org/people/jason.greene%40jboss.com] replied to the
discussion
"Thoughts on hot deployment"
To view the discussion, visit:
http://community.jboss.org/message/559813#559813
--------------------------------------------------------------
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
https://community.jboss.org/thread/155937?tstart=0 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.
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/559813#559813]
Start a new discussion in JBoss AS7 Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]