Hong,
Inline...
Lloyd
On Mar 21, 2008, at 1:33 PM, Hong Zhang wrote:
> Hi, Lloyd
>
>> This is an interesting "development". I hope it's the right move,
>> kitchen sink config can be confusing. Please javadoc each and
>> every element clearly as to its availability with each type of
>> module (in AMX 'ApplicationConfig'); I'll need to understand this
>> and so will end users.
>
> With the TP2 time constraint, I had to focus on getting the war
> related things done first.
> Yes, I will add the missing attributes and also document their
> availability to each type of module. I should be able to check in
> this part soon.
Yes, understood, I should have clarified I didn't expect immediate
action. :)
>
>
>> It does complicate AMX API compatibility--
>>
>> I'm thinking at this point that I can map all the old elements you
>> mention to the AMX 'ApplicationConfig'. This would mean an MBean
>> that would have to return 'null' or some dummy value for the
>> missing attributes.
>
> Do we need to distinguish the case where the attribute is not
> applicable to this module type versus the case where the attribute
> is applicable to this module type but no value was specified for the
> attribute (for optional attributes)?
The only way to distinguish that I can see is to return a magic value
eg 'null'. We could also (possibly) annotate the attributes, marking
their availability somehow eg "you can't set or get this one unless
it's one of the following types".
>
>
>> If this approach is taken, it means we should consider removing
>> all the V2 AMX interfaces for WebModule, EJBModule, etc, an
>> incompatible change to be sure, but probably best if we won't ever
>> register MBeans of those types.
>
> I also like this better. This shield the user like admin console
> from having to deal with both old/new elements.
>
> Thanks,
>
> - Hong
>
>> An alternative is to have both old and new maintained as the
>> existing types. I like this less, because it means that WebModules
>> (for example) could be either AMX type 'ApplicationConfig' or
>> 'WebModuleConfig', which also complicates the JSR 77 runtime picture.
>>
>> Lloyd
>>
>> On Mar 21, 2008, at 10:24 AM, Hong Zhang wrote:
>>
>>> Hi, Lloyd
>>> Yes, the new ApplicationConfig will have more attributes as the
>>> new "application" element now needs to represent all the old
>>> elements (j2ee-application, ejb-module, web-module, connector-
>>> module, appclient-module). So it will need to have a superset of
>>> all the possible attributes of those elements, then additionally,
>>> some new ones, for example, engine.
>>> I don't think we will lose any attributes except in the
>>> "extension- module" case. There is a "module-type" attribute
>>> currently in the extension module, and I don't know if we use the
>>> generic "application" element to represent the extension module,
>>> we will still need this attribute or not. I just looked at the
>>> current ExtensionModuleConfig class, I don't see any get/
>>> setModuleType there, so maybe we don't need to worry about this.
>>> The other part of it is although ApplicationConfig will be used
>>> for all module types in v3, the implementation for the
>>> ApplicationConfig (or Application config bean) is not yet
>>> complete. I have added all the attributes needed by the old web-
>>> module element, and I still need to add the remaining attributes
>>> such as " java-web-start- enabled". This will be easy to do, just
>>> I haven't got a chance to do it yet as it's not needed by TP2.
>>>
>>> Thanks,
>>>
>>> - Hong
>>>
>>> Lloyd Chambers wrote:
>>>
>>>> Hong,
>>>>
>>>> OK, we'll handle both. Maybe AMX can gloss over it by mapping
>>>> both to the same type of MBean, with the older form simply not
>>>> having the newer attributes available.
>>>>
>>>> What I haven't looked at is the delta; does the new
>>>> ApplicationConfig have additionala attributes over
>>>> J2EEApplicationConfig (yes), but does it also lose attributes
>>>> formerly present in J2EEApplicationConfig? In other words, is
>>>> it superset only, or different?
>>>>
>>>> Lloyd
>>>>
>>>> On Mar 21, 2008, at 9:45 AM, Hong Zhang wrote:
>>>>
>>>>> Hi, Lloyd
>>>>> Thanks. And next time when I make any changes in config/amx
>>>>> area, I will make sure to send a separate email to the
>>>>> interested parties. :-)
>>>>> Yes, I think we do need to support the old config elements for
>>>>> the backward compatibility reason. Jerome told me this
>>>>> scenario need to be supported for backward compatility: copy a
>>>>> v2 domain to v3, all the previously deployed application
>>>>> should be able to run.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> - Hong
>>>>>
>>>>> Lloyd Chambers wrote:
>>>>>
>>>>>> Hong,
>>>>>>
>>>>>> I also added getApplicationConfigMap() to DomainConfig.java
>>>>>> and @since Glassfish V3 to the interfaces
>>>>>>
>>>>>> Open question: how are we supporting
>>>>>> com.sun.enterprise.config.serverbeans.J2EeApplication? (that
>>>>>> capitalization is accurate btw)
>>>>>>
>>>>>> Will we support both types of elements?
>>>>>>
>>>>>> Lloyd
>>>>>>
>>>>>> On Mar 20, 2008, at 10:42 AM, Lloyd L Chambers wrote:
>>>>>>
>>>>>>> Hong,
>>>>>>>
>>>>>>> I guess I should have said that I didn't notice a change
>>>>>>> notice in email. I think general email lists are
>>>>>>> insufficient for compatibility changes in part due to the
>>>>>>> very high volume, especially if one is gone for even a few
>>>>>>> days. Whenever possible, "FYI" notes to involved parties
>>>>>>> would be helpful to all. Still, email is lacking in
>>>>>>> general for this purpose. I'm not sure I have the answer
>>>>>>> other than some live "issue queue" into which thing could
>>>>>>> be inserted. Maybe a bug report fills that need eg "need
>>>>>>> AMX support for foo".
>>>>>>>
>>>>>>> Thanks, creating that interface (ApplicationConfig ) will
>>>>>>> solve the problem. But will we still need to support the
>>>>>>> V2 element? If so, AMX might will need to support both
>>>>>>> config elements, but presumably a single JSR 77 MBean
>>>>>>> (since both are a J2EEApplication) so as to stay within the
>>>>>>> model defined by the standard.
>>>>>>>
>>>>>>> Yes, absolutely AMX config and runtime MBeans are
>>>>>>> completely different beasts: an AMXConfig MBean does
>>>>>>> configuration *only*, and a runtime MBean represents the
>>>>>>> runtime state (including statistics and the ability to
>>>>>>> start/stop). The two must not be mixed.
>>>>>>>
>>>>>>> Regarding naming, the types are fixed by convention and
>>>>>>> standard. They *could* be the same, but are not.
>>>>>>>
>>>>>>> For an application-config, the names would be:
>>>>>>> amx:j2eeType=X-ApplicationConfig,name=<app-name>
>>>>>>>
>>>>>>> (The type 'X-ApplicationConfig' is defined by GlassFish, all
>>>>>>> AMX MBeans other than standard ones start with "X-".
>>>>>>> AMXConfig MBeans also must end with "Config").
>>>>>>>
>>>>>>> Its runtime counterpart (which offers a getConfigPeer()
>>>>>>> method BTW):
>>>>>>> amx:j2eeType=J2EEApplication,name=<app-name>
>>>>>>>
>>>>>>> (the type 'J2EEApplication' is defined by JSR 77, a standard)
>>>>>>>
>>>>>>> Lloyd
>>>>>>>
>>>>>>> On Mar 19, 2008, at 9:54 AM, Hong Zhang wrote:
>>>>>>>
>>>>>>>>> In terms of support, adding and AMX Config MBean is trivial:
>>>>>>>>> 1. Define an interface which extends
>>>>>>>>> com.sun.appserv.management.config.AMXConfig. (Actually
>>>>>>>>> this is optional too, but adding an interface is good
>>>>>>>>> for clients who want to use it!)
>>>>>>>>> 2. Annotated the @Configured interface as seen above. You
>>>>>>>>> can even skip step 1 and use
>>>>>>>>> com.sun.appserv.management.config.AMXConfigInfo without
>>>>>>>>> defining an interface.
>>>>>>>>> ... you're done (create/remove sub-elements might require
>>>>>>>>> a little more effort, that's TBD)...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I will create an interface
>>>>>>>> com.sun.appserv.management.config.ApplicationConfig with
>>>>>>>> J2EE_TYPE as XTypes.APPLICATION_CONFIG and my Application
>>>>>>>> config bean will reference this interface.
>>>>>>>>
>>>>>>>> One question I have: are the config beans/amx beans
>>>>>>>> independent from their runtime beans? For example, though
>>>>>>>> the config bean and amx bean called "Application", the
>>>>>>>> runtime beans will still follow the JSR77 naming
>>>>>>>> convention. That is ok, right?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> - Hong
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> Lloyd L Chambers
>>>>>>> lloyd.chambers_at_sun.com
>>>>>>> Sun Microsystems, Inc
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>
>> ---
>> Lloyd L Chambers
>> lloyd.chambers_at_sun.com
>> Sun Microsystems, Inc
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc