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.
>
>
>>>
>>>
>>>
>>> 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
>