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
>