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?
> 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>
What you're really saying is the ordering is representative of an
implementation artifact (in this case, that any EJB's are loaded before
the Web App is).
I think we (NetBeans) need to rethink what an application is and how
things can or should be layered to figure this out. I don't like
depending on arbitrary ordering and I don't think anyone on the server
really wants us doing that either.
>>>
>>> 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.
Great. Nitya, can you track this?
-Peter
>
> - Hong
>