Sorry for not seeing this thread earlier, but now that I got pointed to it after trying out JBoss AS 7 Alpha 1 here are my initial good/bad thoughts about this new approach.
First a little about my assumptions:
JBoss AS 7 is to be usable in todays tools, not the tools of tomorrow. i.e. it should not require magic tools to get a somewhat reliable hotdeployment/development in place.
The experience one had with AS 4 or even AS 3 or heck, even Tomcat is what I aim for - none of this requires special tooling.
Special tooling is what is to be used for *improving* things, not as an excuse to say we can't do it without it ;)
Users can't always run their appserver all the time - with AS 7 it might not be a problem because of smaller memory footprint but once users
start deploying their own stuff to it then that problem returns - hence, most if not all operations should be doable without actually *starting* the appserver.
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.
Good things in the proposal:
Using marker file(s) works for me - that is simple to manage and can be done with and without alot of special plugins/tooling, i.e. ant/maven is easy to do it for - harder for IDE's like Eclipse, Netbeans, etc.
I can live with not having automatic rescan of file changes since tools incl. ant/maven can easily create the additional file to trigger deploy.
Bad/Questionable things:
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 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)
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.
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.
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 ?
With respect to efficient updates/scanning tools (including Ant and maven) could give "hints" to the redeployment by simply listing the files relative to the deployment that actually needs updating - we could put that inside the file marker.
..and again, its great to have a CLI and i'm all for it but I think we can go very far even without it - not all deployments have to be super-safe nor atomic as long as it goes well in "most" cases ;)
One comment I really find wrong is the following from Jason:
"Ok so, I will first start off by saying that the file system is a broken API, for many reasons that I will get into, and that we basically have a bunch of trade-offs here. There is no perfect solution, but I think we should prefer one that is robust. Ultimately we really should push people to using the CLI because then we can get truly intuitive behavior."
or rather, I completely here where this is coming from but the file system is *waay* more accessible and understandable than any CLI we can come up with - it's something we just *have* to support for AS 7 to be easily consumable.
We can always encourage and show by better tooling that the CLI approach is better - but we should still attempt to have a decent hotdeploy operation via file systems - and I don't see why we can't provide that by simply utilizing the marker file concept...