admin@glassfish.java.net

Re: move amx-api into glassfish-api?

From: Jerome Dochez <Jerome.Dochez_at_Sun.COM>
Date: Fri, 14 Mar 2008 23:03:30 -0700

On Mar 14, 2008, at 4:23 PM, Lloyd L Chambers wrote:

> 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
yes, we need this as it is the official way to declare something that
should be registered for remote management.
>
> 2. to make AMXConfigInfo.amxInterface() field be a String instead
> of a Class<? extends AMXConfig>.
sorry but this was not a suggestion, this needs to be changed and we
have talked many times about such use case (no mbean)

>
>
> 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.

So you would want to add some generic AMXian utiilities to hk2 ? There
is no config-api definition in hk2 so I am not sure what you are
suggesting could be moved from amx to hk2. can you clafify ?

>
>
> 2. The amx-api module is no less appropriate than other items in
> common/glassfish-api.


glassfish-api is meant to define the interfaces that can be used to
access and extend GlassFish services. AMX is about remote management,
so although I agree that both are official APIs that we are bound to
support, I don't think they should be merged.

Jerome

>
>
> Lloyd
>
> ---
> Lloyd L Chambers
> lloyd.chambers_at_sun.com
> Sun Microsystems, Inc
>
>
>