Jerome Dochez wrote:
>
> 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
Right. But wouldn't this complicate documentation of --type option?
>
>> 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.
Hmm. But this has its own problems, e.g. having complex combinations
of the base command. We already have that problem on current
deploy command. One command may have too little or too much to
cater for all kinds of "deployment". e.g. deploying an ejb-jar
or an app-client does not have to do anything with --contextroot.
Ultimately, it's a trade-off, IMO. I am not convinced that by
transferring deploy-xxx to --type=xxx our support burden is
reduced in any way.
Also, the commands are extensible. So, say we have a command like
deploy-osgi or deploy-bundle, it's that module's responsibility to
provide this functionality.
>
>> 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
If these are "different", using "deploy" to deploy a jar as an OSGi bundle is
also different from using a "deploy" to deploy a web-app.
I still think that it is a trade-off and probably having distinct
command names is more useful for "users". Maintenance is a difficult
problem either way.
The rule of thumb that I am leaning toward is:
1- derive as much knowledge as you can from the contents of
"archive" or "folder" being deployed, keeping the command
name as "deploy".
2- If ambiguity remains, find a name that suits the purpose.
(This assumes that expectation of users is met w.r.t. the meaning
attached to things. E.g. if a class is annotated as @EJB, it
is an Enterprise Java Bean, not a POJO).
-Kedar
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>