On Mar 18, 2009, at 12:49 PM, 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
Would the deployment framework still be processing the web.xml / sun-
web.xml in this last case? The EJB
code could contain dependencies on it. For example : component
environment entries, EE 6 <module-name> , etc.
I'm not sure I understand the real value of this. If someone really
wants ejb components completely
separated from web components they can just package them in a separate
ejb-jar.
>
> 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
>