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 roadmap.
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 around.
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 either.
There is INFO level logging of where the deployment content is stored (which shoots my #2 above). :-)
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 consistent IMO.
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 ?
Good 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.