Hi Jerome,
I think you raise a really good point and I like the general direction
of this idea...
I have some thoughts I need to collect and I'll write something short up
we can discuss. Not sure if it belongs on this list or not, but as good
as a place as any.
-Peter
Jerome Dochez wrote:
>
> On Apr 10, 2009, at 12:20 PM, Nitya Doraisamy wrote:
>
>> Jerome Dochez wrote:
>>> I agree
>>>
>>> I don't think we should confused application type (there can be
>>> several like ejb, web) with packaging of such applications.
>>>
>>> I am not sure I understand why it is so important for NB to display
>>> per packaging type, they should just use list-applications and then
>>> reorder the way they want. It seems to me that we should either
>>> display per application type (ejb, web) OR you display per
>>> application name and have the containers under.
>> For NB, the plugin display orders the deployed apps by application type
>> (ears, web apps, ejbs, appclients, connectors). For this the code was
>> using the 'nb-engine' value in the MessagePart.
>>
>> But this list for an ear containing a web app contains just <web>. So
>> how can the plugin identify this an ear vs a stand alone web module?
>> Anissa suggested chcking the isComposite property. But then, what about
>> the case of ejb in web app? If the list in this case is <web, ejb> and
>> the plugin can safely assume that the first value will always matche the
>> type of app, then it would work.
>> Will that be the case?
>>
>> The plugin uses this info to identify the type of app and decorate it
>> with appropriate icons. ie. an EAR in the deployed list will have the
>> same icon as an ear project in NetBeans project view.
>>
>> My understanding is that Hong suggested the additional property in order
>> to provide this info. If 'nb-engine' is going to have the appropriate
>> info, then this is not needed. At this point it does not. And if the
>> plan is to remove 'nb-engine' then the plugin needs some way of
>> identifying if the deployed app is an ear, web app, ejb app,
>> appclient etc
>
> that's not the point.
> why do you need to know the archive type ?
> do you want to have 3 levels display in NB :
>
> war:
> foo:
> web, ejb
> bar:
> web, webservices
> jar:
> boo:
> ejb, webservices.
>
> and then with ear you have 4 levels ?
>
> ear:
> war:
> foo module:
> ejb, web
>
> jar:
> bar module:
> web. webservices.
>
> this would also be extremely confusing. My point is that you should
> stop caring about the application packaging type when displaying the
> application tree in NB and just display the application name, module
> list and then containers in which applications or modules are deployed.
>
> Jerome
>
>>
>> - Nitya
>>>
>>>
>>>
>>> On Apr 10, 2009, at 11:23 AM, Kedar Mhaswade wrote:
>>>
>>>> Here we go again, output of command execution == app server API!
>>>>
>>>> Shouldn't you be just listing the applications *by name* and then
>>>> get/process additional meta-data separately? The field "nb-engine"
>>>> sounds
>>>> like a hack.
>>>>
>>>> Let's not add something like --displayPackagingType (i.e. ~20
>>>> characters
>>>> with camel case), on "asadmin list-applications", please.
>>>> Let's not make miserable, the life of command line users.
>>>>
>>>> -Kedar
>>>>
>>>> Nitya Doraisamy wrote:
>>>>> Hong Zhang wrote:
>>>>>>
>>>>>>>>>>> I deployed a ear application containing one web module to
>>>>>>>>>>> the v3 server. The list-applications command shows this
>>>>>>>>>>> deployed app as 'testApp1 <web>'.
>>>>>>>>>>> For a webapp containing enb, the sniffer list returned was
>>>>>>>>>>> <ejb, web>. Shouldn't this be <web,ejb> ?
>>>>>>>>>>>
>>>>>>>>>>> The NetBeans plugin code calls list-applications and uses
>>>>>>>>>>> the response to list the deployed components in a tree.
>>>>>>>>>>> The engine list is used to identify the type of app. The
>>>>>>>>>>> expectation is that the engine sniffer list will be returned
>>>>>>>>>>> and the first engine would be the type of app. The
>>>>>>>>>>> 'nb-engine field' returned was to help the plugin identify
>>>>>>>>>>> the type of app.
>>>>>>>>>>>
>>>>>>>>>>> In a conversation with Jerome & Ludo, it was brought up that
>>>>>>>>>>> the deployed applications will not be identified as ear, war
>>>>>>>>>>> etc instead the tools should show the engines associated
>>>>>>>>>>> with each deployed app.
>>>>>>>>>>> But for a NetBeans developer, it makes more sense if when
>>>>>>>>>>> they a deploy an ear application or a web app, the deployed
>>>>>>>>>>> list in the runtime tree clearly identifies the ear, web
>>>>>>>>>>> apps with appropriate icons.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I kind of agree with you on this one. While in v3, we have
>>>>>>>>>> the concept of converaged application where the application
>>>>>>>>>> could contain more than one components, it still might be
>>>>>>>>>> easier (and more compatible looking as previous releases) if
>>>>>>>>>> we categorize the applications by their packaging types
>>>>>>>>>> instead of the component types inside them. So ejb in war
>>>>>>>>>> case will be categorized as war and ear case as an ear..
>>>>>>>>>>
>>>>>>>>> Yes, it would be great if there was some property which could
>>>>>>>>> be leveraged to identify the type of app? Do you have any
>>>>>>>>> suggestions.
>>>>>>>>
>>>>>>>> Maybe we can add an option to the list-applications command,
>>>>>>>> say, something like "--displayPackagingType=true/false". When
>>>>>>>> it is set to true, it will display packaging type instead of
>>>>>>>> components type. And the default value can be true or false
>>>>>>>> depending what people think..
>>>>>>>>
>>>>>>> So with -displayPackagingType=true, the engine list will list
>>>>>>> the package type and on -displayPackagingType=false, the engine
>>>>>>> list will list the components?
>>>>>> Yes, this is what I was thinking about..
>>>>>>> Or will there be a separate property that provides that package
>>>>>>> type ?
>>>>>> Last time I talked with Jerome, he really did not like the idea
>>>>>> of special property for NB, so we will probably remove it when
>>>>>> making this change.
>>>>>>>>> Currently the plugin is coded to use the first engine as the
>>>>>>>>> type of app If we want to change this to something else, we
>>>>>>>>> need to figure this out soon as NetBeans 6.7 schedule is ahead
>>>>>>>>> of v3's.
>>>>>>>>
>>>>>>>> Can you give a date here?
>>>>>>>
>>>>>>> * Apr 15 - NB 6.7 *Beta Clone*
>>>>>>> * Apr 20 - NB 6.7 *Beta Release*
>>>>>>> * May 25 - NB 6.7 *Code Freeze*
>>>>>>> * Jun 01 - NB 6.7 *RC 1 release*
>>>>>>>
>>>>>> So May 25th is the date we need to have the changes happen?
>>>>>>
>>>>> No, I would like to get this change in happen asap, if possible in
>>>>> the next week or so. So changes that may be needed in the plugin
>>>>> can be flushed out.
>>>>> Nitya
>>>>>> - Hong
>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> - Nitya
>>>>>>>>>
>>>>>>>>>> - Hong
>>>>>>>>>>
>>>>>>>>>>> I don't think they should have to identify it using the name
>>>>>>>>>>> of the app.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Nitya
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> 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
>