Server Runtime, JBossAS should use new file base state change for deploy/undeploy

Simply deleting the files was never a good idea; a kludge at best.

But now JBoss AS7 has extra control file.

It appears to be simple to convert the current tooling to use it.

Instead of deleting the directory you select the file *.deployed.
You then wait and *.isundelpoying (I think) appears.
If you keep waiting you get a *.undeployed file or *.failed.
If a *.failed exists inside is the error reason you can read and report back to used.

To deploy again you create new / touch timestamp on file *.deploy, this file gets removed by the server and then once startup is complete a new file is created by server *.deployed.

Now the STOP actions should:

Delete the file *.deployed (just the 1 file relating to the thing you want to stop). Then the UI should wait, with background table job for the *.undeployed file to appear.

If however there is only the file *.isdeploying you enter a wait loop to wait for the *.deployed to appear. Since the user is trying to stop the module before it has finished starting up.

Re UI waiting there is configuration for server max wait time for start and stop, simply re-use these value for module start and stop. It would be ideal if you have control of the UI dialog that when a wait timeout occurs to indicate to the user so, indicate how long has elapsed and offer to "Keep Waiting another 30 seconds", "Keep Waiting (Forever)", "Force Stop Now". Ideally again with an automatic countdown timer on Force Stop Now with 30 seconds to go. If user has walked away from desk this will trigger, but they have this 30 seconds to override in dialog.

Now the START action:

• Ideally there should be a *.foobar file you can drop to inhibit the AS from taking any action concerning the deployment unit based on the file changes. This would be like an inhibitor file and allows the tooling to perform publishing and modification while this file is set. Once you are done publishing you remove the file. I don't think AS supports this.

• You check if a *.deployed file exists, if so you abort START action and refresh your state based on files.

• To start you public files, then create empty / touch timestamp on *.dodeploy and wait for *.isdeploying to appear and then finally *.deployed or *.failed to appear.

• If *.failed appears you report the error to the user container within and reset the UI state back to STOP.

Sorry if this is all obvious to you.