Dimitris Andreadis [
http://community.jboss.org/people/dimitris%40jboss.org] replied to the
discussion
"Thoughts on filesystem action driven hot deployment"
To view the discussion, visit:
http://community.jboss.org/message/560033#560033
--------------------------------------------------------------
David Lloyd wrote:
> Dimitris Andreadis 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 use the filesystem as their deployment API. :)
> If the cost of deep copying and keeping in synch the exploded archive is not that
high, that would solve the undeploy problems. Although I would personally leave the option
to the user whether to disable deep copy of deployments, either globally (system property)
or per deployment (e.g. META-INF/jboss-no-deep-copy).
Actually this doesn't really solve the problem at all. Say you start deleting your
deployment. At what point does the scanner decide that you're not updating your
deployment by removing files, you're actually deleting it? The same problem basically
exists except now you have the additional complication of having to detect and sync up
changes. My opinion remains: using delete to signal undeploy should not be done,
especially for exploded deployments.
Thus, I don't see any reason to copy exploded deployments. I just don't think it
buys us anything.
I meant it would solve the problem of missing classes/resources
during undeployment.
In any case, I don't think you should worry too much about the timing related problems
of deploying/undeploying exploded deployments. We have this problem for ever and yet very
few complaint because they understand the limitations of the mechanism and how to deal
with it. So IMO simplicity (copy/delete) wins over correctness since the main use case for
altering exploded deployments is development mode.
Production mode users know that to be 100% safe they just need to make the directory based
deployment changes off-line. Or use a proper API that can offer all sorts of guarantees
(e.g. tx behaviour).
So offering the appropriate underying API/functionality to support the more advanced
scenarios while keeping a simple file-based hot-delployment mechanism that people are
familiar with, I think is more important than creating the perfect file-based API
abstraction.
BTW, in some older AS version we added the ability to tell the scanner to ignore/re-enable
a particular deployment, to allow the IDE to make file updates without the fear of the
server picking up incomplete deployments.
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/560033#560033]
Start a new discussion in JBoss AS7 Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]