GlassFish itself - and I think NetBeans - needs to allow for new and
unanticipated container types and module types and engine types as has
been mentioned on this thread already. But that doesn't mean it must be
blind to the "special" types it knows about: ears, wars, EJBs, app
clients, connectors, etc.
As a NetBeans user, I would like to see the familiar icons for the known
types and generic ones for unknown ones. Ideally the developer of the
new container/engine type would have provided NetBeans with a plug-in
that "knows" about that new type and could provide an icon for that type
in a way that NetBeans could use that icon - and any associated logic in
the plug-in - for the new type.
Is that essentially what the existing Java EE support does for what we
think of as the "known" types?
- Tim
Nitya Doraisamy wrote:
> I do agree though that it would be better to list per application name
> and have the modules or containers as child nodes. But do we do away
> completely with identifying of the standard apps (ear, web, ejb ..)
> completeley and just use generic icons or make an attempt to identify
> the type of application. This may be something that the user might
> expect to see coming from the previous incarnations of the UI
> representation for V2 & V3 prelude.
>
> Currently, NB plugin does display the deployed apps similar to your
> description but not quite, the display is
> ear app
> web app name
> ..contents
> ejb module name
> .. contents
> - Nitya
>
> Peter Williams wrote:
>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>