Jerome,
The AMX code does map names back and forth already. But there are no
names to begin with--an MBean operation will be invoked like this:
public final Object invoke(
String operationName,
Object[] args,
String[] types )
There are no argument names here, so nothing to use for mapping. AMX
needs to map args[1..N] to names which can eventually result in xml
property names.
If a method to create an "Abc" eg createAbc() method has been declared
in the AMX interface, then the args could be matched up to the
parameter names, but HOW?
I don't know of any mechanism to get the *names* of parameters from a
java.lang.reflect.Method, or can you? That is why I thought an
annotation was needed, which would allow the names of each parameter
in the parameter list to be named.
Lloyd
On Mar 14, 2008, at 10:44 PM, Jerome Dochez wrote:
> for issue 2, I don't understand why you cannot (at least for 99% of
> the cases) calculate automatically the amx name from the xml name
> and the other way around. seems extremely verbose to me if you have
> to specify it on an annotation when the mapping is simple like in
> you previous email
>
> ex:
> @ParamNames("jndi-name","jndi-lookup-name","res-type","factory-class")
> createJNDIResourceConfig( String jndiName, String jndiLookupName,
> String resType, String factoryClass, Map<String,String> optional);
>
>
> On Mar 14, 2008, at 9:56 AM, Lloyd Chambers wrote:
>
>> Jerome et al,
>>
>> To support AMX create(), I need a few things which perhaps you can
>> tell me how to do—
>>
>> => ISSUE 1: locating an @Configured
>>
>> To locate the @Configured interface corresponding to an AMX
>> j2eeType. This value is found in the @AMXConfigInfo, which
>> annotates an @Configured interface. AMX requires that any module
>> desiring automatic AMXConfig support annotate its config with
>> @AMXConfigInfo. So I need to do this (in some form):
>>
>> for ( final Class<? extends AMXConfig> configIntf :
>> allConfiguredClasses ) {
>> AMXConfigInfo configInfo =
>> configIntf.getAnnotation( AMXConfigInfo.class );
>> if ( configInfo != null &&
>> configInfo.j2eeType().equals( j2eeType ) {
>> // found a match
>> break;
>> }
>> }
>> Such a loop could be run just once (on demand when the first
>> create() is done), and a Map could be created at that time for
>> future efficiency. Alternately, it could exit as soon as the
>> required value were found.
>>
>> Alternately, create() is always implicitly for a child (Containee)
>> and therefore the only classes that need to be searched are those
>> that are child elements of an existing ConfigBean. Is there a
>> method to get all possible child interfaces for a given ConfigBean
>> (not just those that currently exist)?
>>
>> => ISSUE 2: mapping parameter names
>>
>> To support create() methods with explicit parameter lists. For
>> example:
>>
>> createJNDIResourceConfig( String jndiName, String jndiLookupName,
>> String resType, String factoryClass, Map<String,String> optional);
>>
>> The problem here is mapping jndiName, jndiLookupName, resType and
>> factoryClass to XML names; as incoming parameters they are simple
>> indexed values in the parameter list, lacking any sort of name.
>> AMX solves this today by having small mapping tables internally,
>> but that means special code for every such method, something we
>> must avoid in a pluggable system.
>>
>> I’m thinking of using an annotation which specifies the names for
>> explicit parameters:
>>
>> @Target(ElementType.METHOD)
>> public @interface ParamNames {
>> /** comma-delimited list of parameter names, in order */
>> String paramNames default "";
>> }
>>
>> ex:
>> @ParamNames("jndi-name","jndi-lookup-name","res-type","factory-
>> class")
>> createJNDIResourceConfig( String jndiName, String jndiLookupName,
>> String resType, String factoryClass, Map<String,String> optional);
>>
>> Thoughts?
>>
>> Lloyd
>>
>> Begin forwarded message:
>>
>>> From: Lloyd Chambers <lloyd.chambers_at_mac.com>
>>> Date: March 14, 2008 9:36:02 AM PDT
>>> To: admin_at_glassfish.dev.java.net
>>> Subject: Glassfish V3: should AMX preserve create() methods for
>>> backwards compatibility?
>>>
>>> This is a sort of “thinking aloud” and request for feedback all in
>>> one—
>>>
>>> Background
>>>
>>> - In V3 arbitrary modules can be loaded, including ones designed
>>> and compiled after the product ships
>>> - AMX supports configuration MBeans for such modules automagically
>>> with a simple annotation on the @Configured interface supplied by
>>> the module
>>>
>>> In V2, AMX supported creation of sub-elements with createAbc()
>>> methods that included a parameter list with explicit parameters
>>> for required values and optional parameters provided in a
>>> Map<String,String>. Here are a few examples from DomainConfig:
>>>
>>> createStandaloneServerConfig(String name, String nodeAgentName,
>>> String configName, Map<String,String> optional);
>>>
>>> createConfigConfig( String name, Map<String,String> optional );
>>>
>>> createLoadBalancerConfig(String name, String lbConfigName, boolean
>>> autoApplyEnabled, Map<String,String> optional);
>>>
>>> createJNDIResourceConfig( String jndiName, String jndiLookupName,
>>> String resType, String factoryClass, Map<String,String> optional);
>>>
>>> createJDBCConnectionPoolConfig( String name,
>>> String connectionValidationMethod,
>>> String datasourceClassname,
>>> boolean failAllConnections,
>>> int idleTimeoutSeconds,
>>> boolean connectionValidationRequired,
>>> boolean isolationLevelGuaranteed,
>>> String transactionIsolationLevel,
>>> int maxPoolSize,
>>> int maxWaitTimeMillis,
>>> int poolResizeQuantity,
>>> String resType,
>>> int steadyPoolSize,
>>> String databaseName,
>>> String databaseUserName,
>>> String databasePassword,
>>> Map<String,String> reservedForFutureUse );
>>>
>>> Question: In Glassfish V3, should AMX preserve methods like the
>>> ones shown above?
>>>
>>> (and allow/support such methods in new/unknown AMX interfaces
>>> supplied by arbitrary modules)
>>>
>>> I think the answer is “yes”, so long as the backend can implement
>>> this support generically: AMX needs to be able to turn the
>>> parameter list into a generic form (eg a Map) which can be
>>> generically set on a ConfigBean. AMX can supply the “glue” code
>>> to transform the explicit and optional parameters into a form
>>> which can be used to set values on a ConfigBean eg:
>>>
>>> public MyConfig createContainee( final String j2eeType, final
>>> Map<String,String> values );
>>>
>>> implemented by:
>>>
>>> final ConfigBean configBean =
>>> instantiateConfigBeanForJ2EEType( j2eeType );
>>> for( final String fieldName : values.keySet() ) {
>>> configBean.attribute( amxNameToXmlName( fieldName ),
>>> values.get( fieldName ) );
>>> }
>>>
>>> Fortunately, the j2eeType value is found in the @AMXConfigInfo, so
>>> this all ought to work OK.
>>>
>>> Lloyd
>>
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc