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

[Max Rydahl Andersen]

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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> 
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

/max
http://about.me/maxandersen