Jason Greene [
http://community.jboss.org/people/jason.greene%40jboss.com] replied to the
discussion
"Thoughts on filesystem action driven hot deployment"
To view the discussion, visit:
http://community.jboss.org/message/560037#560037
--------------------------------------------------------------
Dimitris Andreadis wrote:
> 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.
The whole problem is the past approach doesnt work *+AT ALL.+ How do you trigger a
redeploy of an exploded directory in a servlet 3.0 application that has no web.xml? So no
matter what we do it will be different.*
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/560037#560037]
Start a new discussion in JBoss AS7 Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]