[jboss-as7-dev] Intended deployemnt behavior?

[Jason T. Greene]

On 7/11/11 11:11 AM, Brian Stansberry wrote:
> On 7/11/11 10:00 AM, Jason T. Greene wrote:
>> On 7/11/11 9:41 AM, Max Rydahl Andersen wrote:
>>> Brian,
>>>
>>>> This is merged (thanks!) along with a fix such that deleting the
>>>> deployment content triggers undeploy[1].
>>>>
>>>> [1] https://issues.jboss.org/browse/AS7-1240
>>>
>>> For clarification - does this "undeploy on deleted content" only apply
>>> to zipped archives
>>> or will it also happen for exploded ?
>>>
>>> And I assume deleting the .deploy will work in any case?
>>>
>>
>> It only applies to things which have auto-deploy turned on. So not by
>> default for exploded.
>
> Not true; it happens whether or not auto-deploy is on. I suppose that's
> not consistent, although it is less convoluted to explain. I'll look at
> how big of a pain it would be to make it only happen when auto-deploy is
> on.
>
> Note that the trigger for undeploy is not the deletion of any file
> inside the exploded deployment. You have to delete the entire directory.
>
> Although you could turn it on and get russian
>> roulette deployment. The biggest problem being that frameworks are
>> surprised when their content disappears before being shutdown. This isnt
>> an issue for archives because we make a copy.
>>
>
> Enabling deletion of exploded content as a trigger for undeploy doesn't
> make it russian roulette. Deleting the content without undeploying first
> is what's russian roulette, whether or not the AS decides to undeploy
> after you do that. Auto-undeploying is like playing with a gun with more
> cylinders; still a bad idea but maybe we undeploy before your app takes
> a user request that blows up in weird and wonderful ways.

Sure but enabling auto-deploy for exploded is russian roulette in 
general since absent an atomic move, it's a race between the scanner 
noticing and the copy operation.

-- 
Jason T. Greene
JBoss, a division of Red Hat