Hong,
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'.
Lloyd
On May 19, 2008, at 11:50 AM, Hong Zhang wrote:
> Hi, Lloyd
> I had some more thoughts after my last reply to your email.
> In v2, we reject the second deployment in your example as it
> attempts to deploy another application with same name but different
> module type. But I start to think that may not be the desired
> behavior in v3. With the concept of converged application in v3, the
> definition of the module type is not as clear as before (the war
> file now can contain EJBs!). And we now have the generic application
> element in the domain.xml to represent application with all
> different module types. Maybe we should accept the second deployment
> in your example as a redeployment (when the deploy --force option is
> specified as true or the redeploy command is used).
>
> - Hong
>
>
> Hong Zhang wrote:
>
>> Hi, Lloyd
>>
>>> Since in V3 all applications are under <applications>, to make
>>> sure I understand:
>>>
>>> - deploy hello.war
>>> - deploy hello.ear => error, name conflict
>>>
>> Yes (though in reality the ear deployment is not supported yet,
>> only the standalone war is supported in v3 today).
>> This is not something new in v3, applications with different module
>> types share the same name space since 8.*.
>> Thanks,
>>
>> - Hong
>>
>>> On May 19, 2008, at 6:28 AM, Hong Zhang wrote:
>>>
>>>> Hi, Arun
>>>>
>>>>>> first of all, Arun is slightly obsolete :
>>>>>
>>>>>
>>>>>
>>>>> It's weird that we have obsolete commands in v3 ;-) I think
>>>>> there should be a separate section that lists such commands.
>>>>
>>>>
>>>>
>>>> I believe this is documented in the cli commands man page. And
>>>> if you try to use deploydir command to deploy in v3, you will
>>>> see a message telling you this command is deprecated:
>>>>
>>>> hzhang_at_nmr:~$ ~/files/sun/glassfish/bin/asadmin deploydir ~/
>>>> deployment/apps/hello
>>>> WARNING : deploydir command deprecated. Please use deploy
>>>> command instead.
>>>> Command deploydir executed successfully.
>>>>
>>>> This command will be removed in the next release after v3
>>>> (backward compatibility rule, deprecated in one release and
>>>> removed in the next).
>>>>
>>>>>> now if the current directory contains a hello.war, a hello.ear
>>>>>> and a hello subdirectory, I am not sure that a system choosing
>>>>>> the "right" file based on an ordering rule that nobody will
>>>>>> know is an advantage. Also considering that most shell do file
>>>>>> completion, it's not that much typing after doing a TAB.
>>>>>
>>>>>
>>>>>
>>>>> It's still inconsistent to me. Using the same command to
>>>>> undeploy whether EAR or WAR sounds still weird, YMMV.
>>>>
>>>>
>>>>
>>>> There is no ambiguity in undeploying the application. The ear,
>>>> war and other module types share the same name space in server
>>>> implementation, so there can only be one application with the
>>>> registration name "hello" at one time.
>>>>
>>>>
>>>> - Hong
>>>>
>>>>>
>>>>>
>>>>>> vince kraemer wrote:
>>>>>>
>>>>>>> That sounds like a great CLI enhancement, to me.
>>>>>>>
>>>>>>> I hate to type. I love it when a tool "does the right
>>>>>>> thing", even if I make a bit of a mistake.
>>>>>>>
>>>>>>> vbk
>>>>>>>
>>>>>>> Arun Gupta wrote:
>>>>>>>
>>>>>>>>> I don't exactly understand the question you are asking in
>>>>>>>>> this e-mail...
>>>>>>>>>
>>>>>>>>> I think you are asking for something like this...
>>>>>>>>>
>>>>>>>>> If the user enters 'asadmin deploy hello', then the operand
>>>>>>>>> will be used as the "root" of a matching scheme...
>>>>>>>>>
>>>>>>>>> The deploy command would search to see if there was a
>>>>>>>>> hello.war or hello.ear or hello.jar or a directory named
>>>>>>>>> hello... in some order...
>>>>>>>>>
>>>>>>>>> The first match found would be deployed.
>>>>>>>>>
>>>>>>>>> Does that summarize your request correctly... or at least
>>>>>>>>> closely?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes
>>>>>>>>
>>>>>>>> -Arun
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I would be a bit concerned about what would happen if there
>>>>>>>>> was a file named hello (with no extension)
>>>>>>>>>
>>>>>>>>> vbk
>>>>>>>>>
>>>>>>>>> Arun Gupta wrote:
>>>>>>>>>
>>>>>>>>>> An application is deployed as:
>>>>>>>>>>
>>>>>>>>>> asadmin deploy hello.war or
>>>>>>>>>> asadmin deploy hello.ear or
>>>>>>>>>> asadmin deploydir hello
>>>>>>>>>>
>>>>>>>>>> and all 3 deployments are undeployed as
>>>>>>>>>>
>>>>>>>>>> asadmin undeploy hello
>>>>>>>>>>
>>>>>>>>>> Now the question ...
>>>>>>>>>>
>>>>>>>>>> Can the deployment be simplified by creating precedence
>>>>>>>>>> rules and making the extension redundant ?
>>>>>>>>>>
>>>>>>>>>> -Arun
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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