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

[Jaikiran Pai]

On Tuesday 25 October 2011 06:58 PM, Max Rydahl Andersen wrote:
> 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 ?
I think the "talkative" log that you are talking about is the message 
that's logged about a missing .dodeploy for deployments, to trigger 
deployment. So yes, this one is different from that scenario.

-Jaikiran

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