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

[jaikiran pai]

jaikiran pai [http://community.jboss.org/people/jaikiran] created the discussion

"Re: Thoughts on filesystem action driven hot deployment"

To view the discussion, visit: http://community.jboss.org/message/593478#593478

--------------------------------------------------------------
> Dimitris Andreadis wrote:
> 
> Treat the deployments directory exactly like in previous jboss versions (i.e. deploy something when is copied, undeploy when is removed) to retain backwards compatibility with user expectation, tools and the like.
> In addition, if you want to go for an atomic deployment of XXX (packed or unpacked), create first a marker file XXX.skip, then copy in the deployment (packed or unpacked) and remove the XXX.skip file when done to trigger the deployment. Voila.
> 
I liked this idea. So here's my initial version of a variant of the current FileSystemDeploymentService  https://github.com/jaikiran/jboss-as/commit/7a8c0d4261842cc45eba312b47f1b0192180db12 https://github.com/jaikiran/jboss-as/commit/7a8c0d4261842cc45eba312b47f1b0192180db12

To summarize, this new OptOutFileSystemDeploymentService allows users to selectively disable processing of deployments (the exact opposite of the current approach). I'm pasting the javadoc here for more clarity:

/**
 * A {@link org.jboss.as.server.deployment.scanner.api.DeploymentScanner} which allows skipping of deployments present in
 * a directory.
 * <p/>
 * The presence of a <fileName>.skip marker file indicates that the deployment named <fileName> has to be skipped
 * during the deployment process. This is useful when a (usually large) deployment file is being copied to the deploy folder.
 * To prevent the deployment scanner from picking up the (incomplete) deployment, the user is expected to <i>first</i> place a
 * <fileName>.skip marker file in the deploy folder and <i>then</i> start copying the actual deployment file. Once the actual
 * deployment file is completely copied, the user should then delete the <fileName>.skip marker file so that the deployment
 * scanner pick up the deployment for processing, during its next scheduled interval.
 * <p/>
 * The contents of the .skip marker file does <i>not</i> matter and it can even be an empty file.
 * <p/>
 * Note that this {@link OptOutFileSystemDeploymentService} is different from the {@link FileSystemDeploymentService} only
 * in the way, the deployment is triggered. In case of {@link FileSystemDeploymentService} the <i>presence</i> of a marker file
 * triggers a deployment (i.e. requires an additional action from the user even for small simple deployments or even when the
 * hot deployment is disabled). On the other hand, this {@link OptOutFileSystemDeploymentService} relies on the <i>absence</i>
 * of a marker file to trigger the deployment processing.
 *
 * @author Jaikiran Pai
 */
public class OptOutFileSystemDeploymentService extends FileSystemDeploymentService {


The main advantage of this scanner is that it allows users to just place their deployments in the deployment folder (either when the server is down or when the server is running) and not worry about any additional marker files. This I guess will cover many of our users. Then for those users who have to disable the hot deployment processing for large deployments, then will first create a *.skip file, then copy over the deployment and once its completely copied, remove the *.skip file.

Note that this new scanner continues to create/delete the rest of the *internal* marker files which Brian already explained. The end users don't really have to worry/care about those, so I did not change any of that behaviour. The only difference in these 2 scanners is related to the trigger that leads to the deployment processing.

I have built and tested this locally for standalone deployments. Worked fine for me. But if anyone else wants to test it out and see how it goes, that would be great. And ofcourse, since this is just the initial version, feel free to express any suitable changes that might be needed. Currently I did not find (or rather did not dig deep enough to find) a way to configure either of these 2 scanners outside of the code, so it's been enabled by default.

Is it worth making it the default scanner in our next release?
--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/593478#593478]

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/20110316/e37570db/attachment.html