What has --force meant historically? Is replacing a war with an ear
consistent with that past meaning?
On May 19, 2008, at 12:32 PM, Jerome Dochez wrote:
>
> On May 19, 2008, at 12:21 PM, Jason Lee wrote:
>
>> On Mon, May 19, 2008 at 1:56 PM, Lloyd L Chambers
>> <Lloyd.Chambers_at_sun.com> wrote:
>>> I think it would be better to reject deployments that are of a
>>> different
>>> type; eg replacing 'war' with 'ear'. This is not a common case,
>>> so it's
>>> likely to be a unintentional mistake. Better to have the user
>>> undeploy the
>>> 'war', the deploy the 'ear'.
>>
>> I agree. I'd hate to be the maintainer of foo.war and start getting
>> support calls on my broken app, only to find out that another
>> developer/admin deployed foo.ear and silently replaced my app. In an
>> ideal world, there would be organizational controls in place to help
>> mitigate that kind of scenario, but we're not always in such a world.
>> :)
>
> right, so this is exactly what we are planning to do by default and
> as long as the --force = true (or redeploy) is not used. So it takes
> an obvious step like specifying the --force=true or use the redeploy
> command to override the foo.war with a foo.ear, I think it should be
> enough right ?
>
> I am not sure that changing an obvious step like using --force=true
> (or redeploy command) into a undeploy/deploy cycle is an added
> security.
>
>
>
>>
>>
>> --
>> Jason Lee, SCJP
>> Software Architect -- Objectstream, Inc.
>> Mojarra and Mojarra Scales Dev Team
>> https://mojarra.dev.java.net
>> https://scales.dev.java.net
>> http://blogs.steeplesoft.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc