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
>