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