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
>