>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
<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?
- Hong