Responses inline.
On Jul 21, 2006, at 10:43 AM, Kohsuke Kawaguchi wrote:
>
>
>> I don't agree with the characterization that "JMX tie your
>> hands". RMI would have been no better, in fact JMX uses the RMI-
>> based connector. Any remote API has limitations, particularly
>> the inability to serialize non-serializable and/or objects tied
>> in some way to the local machine.
>
> I wasn't saying "JMX ties your hands" in terms of comparing it to
> other remoting APIs. What I was trying to say is that exposing the
> underlying remoting API (whether that is JMX, RMI, JAX-WS, or
> anything) directly as an user-level API sounds like a mistake.
>
> Take InputStream as the example. Not many remoting APIs let you use
> InputStream directly, so it has to be turned into byte[]. That's fine.
>
> What's not fine is that you are asking your users to do this
> conversion, when it's your job, as the AMX developer, to do so.
> Your are exposing the complexity that's caused by your underlying
> layer to your users. That's not a good API.
One of the original design goals was to allow JMX clients to use the
API via MBeanServerConnection. Those users (and they do exist!) need
that API.
>
> There are other examples where such limitations in the remoting API
> shows up in AMX. Some of which we discussed in this thread, like
> not being able to pass back object references like WebModule to
> DeploymentMgr.
I don't necessarily agree. Doubling the number of methods (since the
String forum is still useful and required) just increases the
complexity of the API while adding next to nothing:
undeploy( webModule );
undeploy( webModule.getName() );
>
> All such limitations are easily overcome by having little client-
> side library on top of JMX. For example, you could take an
> InputStream from users, then turn it into byte[] inside this
> library, then pass that to JMX. Or your signature could take
> WebModule as a parameter, then take its object name, and pass it to
> JMX.
That client side library *is* the proxy support as it currently
exists. It can be improved, and there are already some helper
classes in com.sun.appserv.management.helper and subpackages. More
can be added as need is understood.
But making the API itself even more huge is a mistake, IMO, since
everything can be done by layering appropriate convenience classes on
top. It's like criticizing the sockets API (C) because it doesn't
have an openSendVerifyAndClose() method; such a method can and should
be written as a supplemental routine that is not part of the core API.
>
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems kohsuke.kawaguchi_at_sun.com
>