Nitya Doraisamy wrote:
> Jerome Dochez wrote:
>>
>> 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
>>>
> 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?
>
> 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?
-Peter
>
> - Nitya
>>> - Hong
>>
>