>
>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think you raise a really good point and I like the
>>>>>>>>>>>>> general direction of this idea...
>>>>>>>>>>>>
>>>>>>>>>>>> Me too... I guess it is time to change this static,
>>>>>>>>>>>> predefined UI representation in the NetBeans tree node and
>>>>>>>>>>>> offer a much more generic way of displaying apps. Who
>>>>>>>>>>>> knows what would be the next type, added by a GlassFish
>>>>>>>>>>>> container we don;t even know yet...
>>>>>>>>>>>> So we need to display the app name as a node and then
>>>>>>>>>>>> either in tool -tip or sub node or properties in the node,
>>>>>>>>>>>> the list of all containers that understand this app.
>>>>>>>>>>>
>>>>>>>>>>> Agree. Thats exactly what GUI is doing now. (see attached
>>>>>>>>>>> screen). As I mentioned earlier, I am thinking that we
>>>>>>>>>>> may have different icons depending on isComposite
>>>>>>>>>>> property, but I really don't know what advantage this
>>>>>>>>>>> gives to user by knowing that its packaged as an ear. Vivek
>>>>>>>>>>> has requested that GUI to display different icon of the
>>>>>>>>>>> app depending on the ruby framework, or application type,
>>>>>>>>>>> eg Rails, Merb, etc. I haven't looked into that yet.
>>>>>>>>>>>
>>>>>>>>>> That's true. It would be ideal to move away from the
>>>>>>>>>> previous representation. But the sticky point is the in
>>>>>>>>>> allowing for displaying a different icon of the app
>>>>>>>>>> depending on the ruby framework, or application type. For
>>>>>>>>>> this you would need to know the application type. So should
>>>>>>>>>> we even try to differentiate using icons or just use generic
>>>>>>>>>> icons?
>>>>>>>>>
>>>>>>>>> I think you should associate those icons with the container
>>>>>>>>> type (web, ejb, webservices). For the top level application
>>>>>>>>> icon, I suppose we could use a generic project/bundle icon no ?
>>>>>>>>
>>>>>>>> Generic icons really don't look very good, especially if the
>>>>>>>> node in question is for an application (e.g. ear)
>>>>>>>
>>>>>>> ok you can always know that a deployed artifacts is an
>>>>>>> application or a module so you could segregate there.
>>>>>>>
>>>>>>> once at the module level, knowing it can be deployed in 1 to n
>>>>>>> containers I think you have to use a generic icon. The item
>>>>>>> under (the container) should have specific icons.
>>>>>>>
>>>>>>> I suppose you could have a feature where you order your view
>>>>>>> according to a setting (sort by name, or sort by container).
>>>>>>>
>>>>>>> Jerome
>>>>>>
>>>>>> Yes, that would work. So how do we identify an application? What
>>>>>> property can be added that provides this data? The 'nb-engine'
>>>>>> list was going to provide this info. Can this be done?
>>>>>
>>>>>
>>>>> not sure what the situation is today but if it does not exist,
>>>>> Hong should add a isComposite flag to the Application config
>>>>> object in the domain.xml.
>>>>
>>>> Jerome:
>>>>
>>>> We already have this property in domain.xml today, see the
>>>> following domain.xml snippet for an ear with a war and ejb jar.
>>>>
>>> good.
>>>
>>>> <application enabled="true"
>>>> location="${com.sun.aas.instanceRootURI}/applications/singleton2/"
>>>> directory-deployed="false" name="singleton2" object-type="user">
>>>> <property
>>>> name="org.glassfish.ejb.container.application_unique_id"
>>>> value="81253144400887808"></property>
>>>> * <property name="isComposite" value="true"></property>*
>>>> <module name="singletonejb.jar">
>>>> <engine sniffer="ejb"></engine>
>>>> <engine sniffer="security"></engine>
>>>> </module>
>>>> <module name="singletonweb.war">
>>>> <engine sniffer="security"></engine>
>>>> <engine sniffer="web"></engine>
>>>> </module>
>>>> </application>
>>>> </applications>
>>>>
>>>> I could add this property to nb-engine list if this is what we
>>>> decide to do. But my understanding is we want to move away from nb
>>>> property?
>>>
>>> yes I want all this nb-property to disappear asap.
>>>
>>> jerome
>>>
>>>>
>> Ok. I can use the isComposite property to identify EAR's. Is it a
>> valid assumption that for a Web Application containing ejb the
>> sniffer list will be <web, ejb>, so I can identify it as a web app?
>
I think Jerome has modified the code so that ejb is always loaded before
web in the ejb in war case, so the list would be <ejb, web>
>>
>> No, please don't remove the nb-property(s) now. Netbeans is going to
>> beta soon and this will break the plugin as it uses these properties.
>
> Maybe the appserver can keep the property for the next 1-2 months AND
> duplicate the data in it's final position. Once NetBeans (post beta,
> but in time for 6.7 FCS) is instrumented to use the correct value, the
> server can remove it.
>
> Is that workable?
Ok, let us know when they can be removed.
- Hong