Jerome Dochez wrote:
>
> 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.
I see. How is "deploy --type=osgi foo.jar" is different from
"deploy-osgi foo.jar"? I see no semantic difference. Maybe an
overloaded (extensible) meaning of --type than extensible commands,
which we already have.
Are you saying keeping "one command" named deploy with pluggable
values for --type is distinctly more beneficial than having
distinct commands that do specific job (which we already support)?
A while ago, you opined that having "higher level commands" with
clear "names" have a huge value. I am wondering if that contradicts
with this ...
-Kedar
>
>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>