[jboss-dev-forums] [JBoss AS7 Development] - Thoughts on filesystem action driven hot deployment

[Dimitris Andreadis]

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&containerType=14&container=2225]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20100901/d4d6f897/attachment.html