On Mar 18, 2009, at 11:27 AM, Kedar Mhaswade wrote:
>
>
> 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"?
none
> I see no semantic difference. Maybe an
> overloaded (extensible) meaning of --type than extensible commands,
> which we already have.
>
that's right, I think having a different command name per type would
be a waste of documentation, code and resources. it's a lot more
expensive to create and maintain
> 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)?
>
yes although this is a free world so extensions can come with their
own "deploy" style commands. it is just they force people to learn
that command and its parameters rather than leverage ours. On top of
that, having separate commands will prove difficult to maintain
consistency between them in the future.
> 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 ...
>
not at all, I did not want to see semantically different commands
having the same name, like
asadmin create http-listener
or
asadmin create iiop-listener
here I want semantically equivalent methods to use the well known
"deploy" pattern.
jerome
> -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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>