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

[Jaikiran Pai]

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