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.
> 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)?
> 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
>