Tim,
XTypes is definitely not a requirement in V3. The issue at present is
where those 300 values or so would go! For example, I might move all
the Config ones to the @AMXConfigInfo annotation. Or maybe they
should just be defined in the AMX interface itself (better).
The idea of an AMX interface has historically been:
(a) to javadoc the available attributes and operations of the MBean
and to formalize the public API of that MBean;
(b) to make it easy for clients to create a dynamic proxy, which
greatly simplifies access.
(c) to allow navigation to children ("Containees") and the parent
("Container") of the MBean.
Going forward with pluggable modules both (a) and (b) are no longer
centralized; one must deal with modules on a case-by-case basis eg
finding the javadoc somehow. The AMX interface would presumably be
part of the module itself, so any module wanting an AMX interface
would need to depend on the exporting module.
The reason to supply an AMX interface for an @Configured are the same
a/b/c reasons given above. But it is not planned to be a
requirement. I am looking into a generic AMX client interface, with
convenience methods.
AMX for V3 is planned to work generically against any @Configured
object. But AMX currently requires an interface to be specified via
@AMXConfigInfo on the @Configured interface. That interface must
extend com.sun.appserv.management.config.AMXConfig. This requirement
will be relaxed; AMX can and will support @Configured interfaces
lacking an AMX interface. Probably the default will be an
GenericAMXConfig interface, supporting any @Configured that has not
specified and AMXConfig interface. There are issues (eg the
j2eeType), but I think it's otherwise straightforward.
...
EXAMPLE of how an @Configured specifies its AMX interface:
@AMXConfigInfo
( amxInterfaceName="com.sun.appserv.management.config.DomainConfig",
singleton=true, omitAsAncestorInChildObjectName=true)
@Configured
public interface Domain extends ConfigBeanProxy, Injectable,
PropertyBag { ... }
...
Finally, how to define the AMX API in light of pluggable modules is an
open question (and it's even an open question as to whether the API
should persist in its present form, perhaps it should be much more
generic). For that matter, JMX seems to be of less interest in
general, would the world be offended with no JMX support? I don't know.
Lloyd
On Jun 24, 2008, at 10:35 PM, Tim Quinn wrote:
> Hi, Lloyd.
>
> If I understand the idea here it would work very smoothly for the
> prelude release in which we need to deal only with web apps. And
> even in the EE 6 release for the other java EE module types to
> handle (EARs, etc.) similar sorts of changes would work.
> Which brings me to the case of additional, non-Java-EE module types
> that already exist or could come into existence later (ruby, for
> example). We would ask the people building the container, sniffer,
> deployer, GUI plug-in, etc. for the new module type to do what
> you've described for whatever editable information they want to
> persist in domain.xml. What if these are not Java EE module types
> but something different? Are the same steps required - changing
> XTypes.java for example? Since those classes or interfaces would be
> in a separate module that contains other implementation classes for
> that module type, would AMX be OK with that?
> Because we cannot know in advance what module types may appear in
> the future, what about a looser coupling between AMX and the
> particulars of a given module type. For example, we're proposing
> that the existing <appliation-ref> element gain some new lower-level
> structure to hold the customizations the user applies. What if we
> standardized on <custom> (or perhaps some better element name) as a
> single added (optional) child to <application-ref> and AMX provided
> a way to return the XML as text that dangled below <custom>?
> That way, only the classes and interfaces directly related to the
> module type would be concerned with the structure that appears below
> <custom>. The engineering team that implements the classes for
> supporting the new module type does not need to modify any classes
> or interfaces in GF itself in order to incorporate their new module
> type into v3. This would be a little less convenient to the code
> that needs to work with the content below <custom> since that code
> would need to parse the XML fragment or use JAX-B or something like
> that. But it would be a little more convenient in that the
> engineers would not need to define the bags you mentioned or make
> any changes to central classes in GF (which I guess XTypes.java is).
>
> - Tim
>
>
>
> Lloyd L Chambers wrote:
>> Hong,
>>
>> This seems straightforward; it's more or less the same as doing
>> Property or SystemProperty.
>>
>> There are two parts to this: (1) extending the @Configured
>> interface, and (2) extending the AMX interface for that @Configured
>> interface.
>>
>> Recently the @DuckTyped support has gone into the HK2 Config API,
>> which makes things easier. My instructions here are based on how
>> that appears to work.
>>
>> 1. Define an EnvEntryBag and ContextParamBag, mimicking
>> com.sun.enterprise.config.serverbeans.PropertyBag (same package).
>> You need not provide all the same methods.
>>
>> 2. Modify com.sun.enterprise.config.serverbeans.WebModule to extend
>> those Bag interfaces:
>> public interface WebModule extends ConfigBeanProxy, Injectable,
>> Module, PropertyBag, EnvEntryBag, ContextParamBag {...}
>>
>> The AMX interface is optional, but really the only way to javadoc
>> things as well as the only way to allow ease of client access in a
>> POJO-like manner.
>>
>> 3. Create AMX interfaces
>> com.sun.appserv.management.config.EnvEntryConfig and
>> com.sun.appserv.management.config.ContextParamConfig files (new
>> files). Use AMX PropertyConfig as a example, but you need not have
>> all the same methods. You will need to add a J2EE_TYPE value for
>> each in XTypes.java.
>>
>> 4. Modify com.sun.appserv.management.config.WebModuleConfig to add
>> the following methods (implementation should be automatic):
>> public interface WebModuleConfig extends ... {
>> ...
>> public EnvEntryConfig createEnvEntryConfig(...);
>> public void removeEnvEntryConfig(String name);
>> public Map<String,EnvEntryConfig> getEnvEntryConfigMap();
>>
>> public ContextParamConfig createContextParamConfig(...);
>> public void removeContextParamConfig(String name);
>> public Map<String,EnvEntryConfig> getContextParamConfig();
>> }
>>
>>
>> Lloyd
>>
>> On Jun 24, 2008, at 11:26 AM, Hong Zhang wrote:
>>
>>> Hi, Lloyd
>>> We were talking with admin console team about implementing part of
>>> the application management feature in v3.lite. Some questions came
>>> up w.r.t AMX API.
>>>
>>> We were told the admin console read/write domain.xml through AMX
>>> API. And this is our current plan for domain.xml:
>>> 1. We plan to store the user customized values under application-
>>> ref element.
>>> 2. For each module type, there will be a few entries which we
>>> allow user to edit. So the top level sub-element is probably a
>>> module element. And then there will be the actual entries with
>>> their names and values. For v3.lite, say we plan to support the
>>> editing of env-entry and context-param of web module, so it will
>>> be something like this:
>>> <application-ref ...>
>>> <module type=web>
>>> <env-entry name=foo1 value=bar1/>
>>> <env-entry name=foo2 value=bar2/>
>>> <context-param name=foo3 value=bar3/>
>>> <context-param name=foo4 value=bar4/>
>>> <module/>
>>> </application-ref>
>>>
>>> So the question is what it takes for the admin console to read/
>>> write the above in domain.xml. The list of editable entries which
>>> are allowed for each module type might be different. And the list
>>> of editable entries for a particular module might grow. What's the
>>> best way to do this?
>>>
>>> Thanks,
>>>
>>> - Hong
>>
>> ---
>> Lloyd L Chambers
>> lloyd.chambers_at_sun.com
>> Sun Microsystems, Inc
>>
>>
>>
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc