On 7/11/11 11:15 AM, Jason T. Greene wrote:
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.
True. Seems we're going back and forth expanding on the russian-roulette
nature of not using the marker files with an exploded deployment. :-)
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat