On Apr 15, 2009, at 12:47 PM, Hong Zhang wrote:
>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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
>
> - Hong