[jboss-as7-dev] File system deployment - Handling .failed markers on server restart

[Jaikiran Pai]

A user brought up an issue (or rather a non-intuitive behaviour) with 
the way we process failed file system deployments. Consider the 
following case:

1) User has a foo.war in standalone/deployments folder and that foo.war 
is dependent on some setting in the standalone.xml
2) The standalone.xml has an inconsistency which results in the 
application deployment to fail when the application is deployed
3) Our file system deployment process creates a foo.war.failed marker to 
indicate that failure and to suppress any subsequent re-deployments 
until the issue is fixed. The file system deployment scanner picks up 
the foo.war for re-deployment if that foo.war.failed marker is removed 
or the timestamp of the foo.war changes to a more latest timestamp than 
that of the .failed marker.
4) In this user's case, since the cause of failure was a configuration 
issue in the standalone.xml, the user stops the server and fixes the 
standalone.xml
5) He then restarts the server, but our file system deployment scanner 
does *not* pick up foo.war for deployment (nor logs a message) since 
neither the .failed marker was removed nor the deployment foo.war had a 
new updated timestamp.
6) The user then has to go figure out why the deployment was never 
picked up.

I personally don't think we should do any additional (smart?) logic in 
the file system deployment scanner to handle this scenario. I would 
expect the user to either remove that .failed marker or update the 
deployment timestamp once he has fixed the (external) issue. *But* I do 
think that we should probably log a (one-time) INFO message during 
startup to indicate that the presence of the .failed marker has caused 
the scanner to skip the deployment.

Thoughts?

-Jaikiran