Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com
] created the
"Re: Thoughts on filesystem action driven hot deployment"
To view the discussion, visit: http://community.jboss.org/message/570368#570368
Thanks for the input. I was off yesterday; hence the slow reply.
Max Andersen wrote:
Local and remote deployment are different things, but both have usecases for
hotdeployment functionallity - i.e. me updating a html page shouldn't require a full
restart of an app, even if running remotely on an EC2 server for my testing.
I'm interpreting this as a request for a remotable API to allow users to 1)
upload exploded deployments and 2) upload individual files to change the contents of those
deployments. If that's correct, can you file a JIRA, as that isn't on any
I don't understand why you have to *remove* the deployed files -
if they aren't locked by appserver then please keep them there otherwise tooling have
to constantly copy all content to the location (this is not a problem in toy samples, but
take a Seam EAR, that is over 20MB of data....that takes time, CPU and disk IO on even the
fastests systems - if I touch a html file - tools should not need to copy all again)
For exploded content the intent is to leave the original file there. The assumption
is the reason people use an exploded deployment is they want to be able to manipulate its
contents, so deleting it would be non-sensical. :)
For Zipped archives we still have to copy all so that is less of an
issue - but why not keep the file there so users can actually see what got deployed and
they can adjust content as they need ? (I really find this "delete what got
deployed"-approach weird..I don't understand the reasoning)
What do you mean "they can adjust content as they need?" Only thing I
can think of is to replace the zip with another version.
I'm OK with leaving the original deployment around. Jaikiran commented way back that
removing it forces the user to keep a copy of it around somewhere else.
The logic for removing it is once the scanner has picked up foo.war and deployed it, the
foo.war.deployed file is what matters. Deleting that file is what triggers undeploy.
Deleting foo.war itself does nothing., and leaving the file there leads people to believe
that deleting it means something.
I know that's a bit inconsistent though, since copying in a new version of foo.war
does trigger a deployment action.
If we're going to leave the original file around, for zipped files IMO we should do
away with the marker files, and use them solely for exploded deployments, where they have
a clear purpose. If the zipped files are left around, the only thing the marker files
provide is an indication that the content was actually deployed. There are other ways to
see that; and by itself that's not justification for the confusion of having two files
How are users to know where the actual deployment is happening from ?
Suggestion: put a deploy.location=/var/tmp/blahbla/foo.war into the marker file - simply
for ease of debugging/transparency.
I've been tempted to do that. Haven't
because 1) it forms a semi-contract that I'm not sure we should commit ourselves to.
2) It also encourages poking around in places users aren't meant to go poking. 3) It
also forces the deployment content repository to expose internal implementation details to
the deployment scanner service, which isn't the end of the world but isn't nice
There is INFO level logging of where the deployment content is stored (which shoots my #2
Why have markers both at toplevel /foo.war.deployed and
foo.war/META-INF/jboss-deploy - why not just have them as foo.war.deploy (request
deployment of foo.war) and foo.war.deployed (marker for foo.war have been deployed) ? More
Fine with me.
Another issue is though how is all of this going to work for updates
that should not trigger a full restart of a module ? i.e. updating html/xhtml pages does
not force a restart of a module which causes current sessions to be destroyed ?
question. We'd been talking in terms of having the exploded content in deployments/
directly mounted, i.e. being directly used as the deployment content. The marker files
would serve to trigger deploy/undeploy/redeploy. Once the content was deployed, changes in
the content, e.g. a new deployments/foo.war/index.jsp, would be immediately visible.
The downside to that is multiple changes can't be made as an atomic unit, with no
requests seeing only some of the changes. But I don't think that's a critical use
case. Devs doing testing will deploy content, make some requests, update some files in the
deployment, make some requests, etc. They're not making requests in the middle of
copying in changed files.
Reply to this message by going to Community
Start a new discussion in JBoss AS7 Development at Community