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