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

[Brian Stansberry]

On 10/25/11 6:11 AM, Jaikiran Pai wrote:
> 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.
>

Agreed. Although not exactly boot time. The first time the scanner runs 
after starting. In 99.9% of cases that's at boot. If the user stops and 
restarts the scanner after boot they'd likely also want the same 
information if there was a problem.

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


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat