David Lloyd wrote:
Brian Stansberry wrote:
Is it easier just to copy the exploded deployment and have the scanner keep the copy in sync. I've done that for farming; it's not such a big deal. I'm starting to feel like not doing that is leading to a lot of internal complication (e.g. needing to keep track of multiple locations where content is stored.)
That doesn't solve the atomic move problem, but maybe if people can't do atomic moves they should [not] use the filesystem as their deployment API. :)
For a single JAR it's a much simpler proposition to avoid partial copies than it is for exploded deployments. One merely has to ignore files which were modified in the past, say, 500 ms. This very greatly reduces the likelihood of a partial copy without really sacrificing latency significantly.
This doesn't work for directories as most filesystems won't update the directory timestamp when one of its children are updated, and in no cases I can think of offhand for deep children.
You know if you look at AS4 behavior from the user perspective the proposal it not really THAT different.
Instead of touching web.xml for a redeploy they touch "jboss.redeploy" or whatever. The only real significant difference is where jboss.redeploy does not exist until they want it to start. But hey they can still do it the old with atomic moves, just leave a jboss.redeploy file in there and do the atomic move.