I like an INFO "Deployment foo.war skipped because of failed marker" Maybe a boot time report: working.ear : deployed foo.war : skipped, failed marker detected disabled.jar : skipped, skipdeploy marker detected

Carlo On 10/25/2011 10:15 AM, Jaikiran Pai wrote: > 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 > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I thought I already seen the file scanner be "talkative" in the logs about why it does things because of various markers… maybe this special case is not covered ?

/max On Oct 25, 2011, at 10:23, Carlo de Wolf wrote: > I like an INFO "Deployment foo.war skipped because of failed marker" > > Maybe a boot time report: > > working.ear : deployed > foo.war : skipped, failed marker detected > disabled.jar : skipped, skipdeploy marker detected > > Carlo > > On 10/25/2011 10:15 AM, Jaikiran Pai wrote: >> 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 >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev /max http://about.me/maxandersen _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev