On Mar 17, 2008, at 10:17 AM, Lloyd L Chambers wrote:
> 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 understand now, thanks
> I don't know of any mechanism to get the *names* of parameters from
> a java.lang.reflect.Method, or can you?
no there isn't a way to do that with reflection but we could use APT
to generate that information automatically.
where would these createABC be located ?
Jerome
> 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
>
>
>