Jerome,
// comments stripped
public @interface AMXConfigInfo {
Class<? extends AMXConfig> amxInterface() default AMXConfig.class;
String j2eeType() default "";
String nameHint() default "name";
boolean singleton() default false;
boolean omitAsAncestorInChildObjectName() default false;
}
You made the following suggestion when we talked a few days ago:
1. wanting to move @AMXConfigInfo into glassfish-api
2. to make AMXConfigInfo.amxInterface() field be a String instead of
a Class<? extends AMXConfig>.
I don't like #2 because it moves compile-time errors into the runtime
realm, and in reality once one uses @AMXConfigInfo, it's useful to
extend the AMXConfig interface to do useful things.
Is there really a use case whereby @Configured items are going to used
with no support for MBeans, but the same @Configured items will be
used with MBean support elsewhere? I am skeptical that this case
exists; it seems likely that no CLI support would exist in that case
either (and what about dotted names which are likely to use AMX
MBeans?).
Other thoughts:
1. AMX is nearly generic enough that a subset of it would be highly
appropriate for HK2 itself. I have stripped V2 special cases from the
V3 implementation and there is very little that is inappropriate for
HK2. However, a consistent naming scheme for MBeans and a base
interface for all and navigational methods are valuable and should
remain.
2. The amx-api module is no less appropriate than other items in
common/glassfish-api.
Lloyd
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc