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
>>
>>
>>
>