Max Andersen [
http://community.jboss.org/people/max.andersen%40jboss.com] created the
discussion
"Re: Thoughts on filesystem action driven hot deployment"
To view the discussion, visit:
http://community.jboss.org/message/570085#570085
--------------------------------------------------------------
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...*
*
*
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/570085#570085]
Start a new discussion in JBoss AS7 Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]