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

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