dev@glassfish.java.net

Re: new deploy command parameter

From: Jerome Dochez <Jerome.Dochez_at_Sun.COM>
Date: Wed, 18 Mar 2009 09:49:38 -0700

On Mar 18, 2009, at 6:21 AM, Kenneth Saks wrote:

>
> On Mar 18, 2009, at 9:04 AM, Hong Zhang wrote:
>
>>
>>>>
>>>> The proposal didn't specify, so this is an optional parameter ?
>>>
>>> yes
>>>
>>>> And we are assuming that the user will know exactly what type to
>>>> specify ?
>>>
>>> yes otherwise, it should not specify anything and let the server
>>> sort it out
>>>
>>>> is this type the same as the name of the 'sniffer' ?
>>>
>>> yes
>>
>>
>> In case of ejb in war, what type should it be if user were to
>> specify one? I assume for ear case, it should be "ear".
>
> Is a .war one of the bundles that we expect difficulties in
> identifying? If so, it would be better just to identity as
> a .war and let all the normal .war packaging semantics apply.

This is what would happen when people do not specify the --type
parameters. From Hong's example, it's clear that the only interest of
specifying the --type parameter would be to say that you want to
deploy the web-app part but not the EJB (used as pojo) for instance

so you can do

deploy --type ejb,web -> would deploy in both container.
deploy --type web -> only web container
deploy --type ejb -> only ejb container

Jerome

>
>>
>>
>>>>
>>>>
>>>>
>>>> Timothy Quinn wrote:
>>>>
>>>>> Adding --type to the deploy command makes a lot of sense to me.
>>>>>
>>>>> Let's allow a comma-separated list of types.
>>>>>
>>>>> - Tim
>>>>>
>>>>> Jerome Dochez wrote:
>>>>>
>>>>>> Hi All
>>>>>>
>>>>>> I would like to propose adding a new parameter to the deploy
>>>>>> command, --type.
>>>>>> With new converged applications, it is becoming increasingly
>>>>>> difficult to determine the application type being deployed.
>>>>>> Although we can figure out in most cases, I believe there will
>>>>>> be a few corner cases where several outcome is possible.
>>>>>>
>>>>>> For instance, say an OSGi bundle contains some servlets (maybe
>>>>>> to remotely configure the module's capability), and some
>>>>>> Spring components. Should it be deployed as a plain OSGi
>>>>>> bundle and used as a library to other application, should it
>>>>>> be a Spring app or should it finally be a web-app. Maybe it
>>>>>> should be all of it.
>>>>>>
>>>>>> Not specifying the --type parameter will ensure that all
>>>>>> appropriate containers get to deploy the application, so in
>>>>>> this case, the OSGi exported packages are available, web-app
>>>>>> and spring components are deployed correctly. But maybe the
>>>>>> user intended to only use this jar as an OSGi bundle and
>>>>>> nothing else. In such case, --type osgi should be used to
>>>>>> deploy that artifacts.
>>>>>>
>>>>>> I can think a many more cases, but give me any feedback you
>>>>>> might have.
>>>>>>
>>>>>> Jerome
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>