Sorry for the slow response; finally freed up a bit.
Please have a look in the AS codebase, cluster module, classes org.jboss.ha.framework.server.FarmMemberService and ClusterFileTransfer. Discussion below is based on those classes; those are what you'd need to build off of.
The basic problem with exploded deployments in farming is that on all nodes in the cluster there is a thread that's looping and scanning the farm folder. If that thread detects a change of the deployment's standard descriptor file while you're in the middle of copying your new exploded deployment, the deploy/farm operation will begin prematurely. This is a problem with deployments in the deploy dir as well, but the latency added by copying files around the network makes this even more of an issue with farming.
Probably the simplest workaround for this is to add mbean operations to the farm service that allow you to stop/restart the background thread. With this approach, deploying via farm wouldn't be as simple as a simple copy to farm, but it could be done. Process would be:
1) Invoke the new "stopScannerThread" operation.
2) Copy your updated deployment to farm.
3) Invoke the new "startScannerThread" operation.
4) deploy() method gets invoked.
5) before replicating files around cluster, deploy() executes a RPC call to the cluster to stopScannerThread
6) deploy() replicates files around the cluster
7) deploy() executes an RPC call to startScannerThread().
For ease of operation, steps 1-3 could probably be scripted using twiddle, or packaged into a custom ant task. Any code that could invoke the stop/startScannerThread mbean operations would do.
As for replicating multiple files instead of just one, deploy()/undeploy() would need to be changed to walk the directory tree referenced by DeployURL and replicate all files.
To only replicate changed files, you'd need to maintain a map of file names to lastModified dates so you could do the comparison in the deploy() method.
Of course all this needs to be bulletproof so you don't accidentally permanently stop the scanner thread or break things in other ways I'm not thinking of!
thanks for the reply. Lots of good info for me in there.
Is this something that you guys (JBoss) are looking at? Or am I the only one who wants this sort of thing?
i.e. is this a potential future enhancement, or would I be on my own to implement this for our use?
This isn't something that's on our short to medium term roadmap. If you developed and contributed it, I'd help you out as I could and if it works out we could add it to the JBoss code base and maintain it.