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

On Tuesday 25 October 2011 01:53 PM, 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 That's a good idea.

-Jaikiran > > 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 _______________________________________________ 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