Lloyd,
Please see inline..
Lloyd L Chambers wrote:
> 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.
I would like some clarification to this.
I am hearing that there will still be <web-module>, <ejb-module> in
V3's domain.xml for compatibility, but there will NOT be AMX interface
to get to this element, is that correct ?
If thats true, there will be additional AMX API that will return ALL
the web apps deployed, ie, include both <web-module> AND <application>
which has 'web' specified in the engine. I think this is what Jerome
suggested in Thurs' eng. meeting.
Can Lloyd confirm ?
thanks
Anissa.
>>
>> 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
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>