dev@glassfish.java.net

Re: a more sensible AMX API

From: Lloyd L Chambers <Lloyd.Chambers_at_Sun.COM>
Date: Fri, 21 Jul 2006 13:23:38 -0700

Responses inline.

>
> That would allow you to expose more sensible management API (which
> uses JMX as the underlying layer.) That's what I wanted to see as
> "the management interface for Glassfish", and that's what I wanted
> to see advertized.

98% of the API doesn't expose JMX in any way.

As a specific example, where is not "sensible" about 'SSLConfig'? In
what way does it expose JMX? 98% of AMX is composed of interfaces
that are of this nature (getters, setters). There simply are no JMX-
isms in such interfaces.

public interface SSLConfig extends ConfigElement
{
        public static final String J2EE_TYPE = XTypes.SSL_CONFIG;
        
        public String getCertNickname();
        public void setCertNickname( String value );

        public boolean getClientAuthEnabled();
        public void setClientAuthEnabled( boolean value );

        public String getSSL2Ciphers();
        public void setSSL2Ciphers( String value );

        public boolean getSSL2Enabled();
        public void setSSL2Enabled( boolean value );

        public boolean getSSL3Enabled();
        public void setSSL3Enabled( boolean value );

        public String getSSL3TLSCiphers();
        public void setSSL3TLSCiphers( String value );

        public boolean getTLSEnabled();
        public void setTLSEnabled( boolean value );

        public boolean getTLSRollbackEnabled();
        public void setTLSRollbackEnabled( boolean value );
}



>
> Users are lazy, and they expect a good developer experience.
> Exposing JMX proxy interfaces as the API just doesn't cut it.

The AMX proxies are implementations of the AMX interfaces, using
java.lang.reflect.proxy. They are INDISTINGUISHABLE from any other
implementation of those interfaces. They are NOT "JMX interfaces".
They are Java interfaces, which JUST HAPPEN to be implemented using
java.lang.reflect.proxy.


>
>
>>> But then, I think you are saying that that was indeed the
>>> initial goal, but resourcing issue forced you to change the
>>> plan, so I guess there's nothing that can be helped there. Thank
>>> you very much for the explanation.
>> I was referring *only* to the DeploymentMgr.
>> If you feel there are other tasks which belong *in the API*, as
>> opposed to sample code and/or utility code which is layered on top
>> of the API, please send those comments along and I'll provide
>> the examples for starters, and see where the best place to add
>> them might be.
>
> From my limited exposure to AMX, the scope of tasks that it covers
> seems to be adequate. It did seem to have everything I wanted. What
> was not adequate was the way it was exposed to me.

Please be specific about anything I did not address.

>
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems kohsuke.kawaguchi_at_sun.com
>