On Mar 18, 2009, at 10:06 AM, Kedar Mhaswade wrote:
>
>
> 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?
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?
of course. in the absense of --type, all applicable container are used.
> 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).
>
the point is when you don't own the packaging.
Take a slightly different situation, don't take the ejb+war but osgi
+ejb.
Say someone as an OSGi library that can be used a shared library but
also offers some EJB components. So far we cannot offer such support
in v3, having a EJB application export packages as a library through
OSGi. Yet upon deployment, what should we do, should we consider the
artifact a pure OSGi library (like if it was placed in modules) or
should we reduce it to just an EJB application. so if the user does
deploy foo.jar -> deployed in the EJB container, OSGi export package
is not honored.
deploy --type osgi foo.jar -> deployed as an OSGi library, no EJB
components installed.
sometimes, there is a need to disambiguate what to role of an artifact
is intended to be used at, especially in the converged world.
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>