Jerome Dochez wrote:
>
> 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
If a .ear is the archive, everything will be deployed from there, without
requiring any --type, right?
Alternatively, I am not understanding the value of the proposal if I have
got a .war with EJB's in it and not deploying those EJB's to the EJB
container. Isn't that logical that EJB's are treated as EJB's and not POJO's?
Wouldn't it be more confusing for the developers to bundle 'n' components in
an archive and then deploying only a subset of them? (If they want to deploy
a subset, maybe it is easier to just bundle that subset).
BTW, how does this relate to the presence and/or absence of deployment
descriptors?
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>