Lloyd L Chambers wrote:
>> 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() );
For the higher level API that I'd love to use, I don't want
undeploy(String). I'm not saying that you should expand the current JMX
interfaces for the higher-level purpose (as you point out, that's just
not possible since this interface has to be JMX-compatible.) I'm saying
you should build more sensible API on top of it, that hides the
lower-level limitations of JMX-origin from users.
Also, when you have a better type that represents a web module, you
should always use that, as opposed to accept a string "handle" that
somehow identifies the module. It removes the guess work from users, who
have to think about what those strings are and where to get it from.
Static type safety is a good thing.
(And in any case, "undeploy" should be a method on webModule, so the
above code should really become "webModule.undeploy()")
> 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.
Helper class doesn't hide the underlying lower-level details. So it
doesn't help here.
> But making the API itself even more huge is a mistake, IMO, since
> everything can be done by layering appropriate convenience classes on
> top.
Agreed. What I'm asking is exactly adding one more such layer that hides
this lower-level API, which is IMO skewed unnaturally because it has to
be JMX compatible.
> 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.
If what I was asking is deployStartWait30secThenStop(), then you are
right. But I'm not talking about the granularity of the operation. I'm
quite happy with the current AMX in that respect. Instead, I'm talking
about the way those operations are exposed.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com