Lloyd L Chambers wrote:
> 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.
Perhaps. It could be that the part that I looked at included the other
2%. Maybe that's why it looks to me a bigger problem than it looks to
you. That's possible. I'm just extrapolating what I saw.
> As a specific example, where is not "sensible" about 'SSLConfig'?
Yeah, this looks quite sensible.
>> 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.
What I'm trying to point out, is that the fact that the interfaces need
to work with JMX restricts the way you can design the interfaces, and
that's showing. Like the fact that you used byte[] where it should have
been InputStream. Or like the fact that you couldn't use
J2EEDeployedModule as a parameter to DeploymentMgr.
Those things add up.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com