Comments inline.
On Jul 21, 2006, at 2:36 PM, Kohsuke Kawaguchi wrote:
> 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.
There is nothing JMX-based about using a String. It is a very good
choice in some cases. The JMX issue is irrelevant. AMX *can*
support both:
undeploy( String moduleID );
undeploy( J2EEModule module );
There are many such cases. I don't think it's worth turning 100
methods into 200 to accomplish this.
>
> 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()")
And for every other type of module, too.
>
>
>> 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.
You keep repeating this. There is nothing "low level" about using a
String identifier as a name. Developers enter the name, developers
can supply the name at deployment time, and developers see the name
in the GUI!!!
>
>
>> 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.
Your conclusion is wrong. The choice of String is not because it is
JMX compatible. It is because it is *useful* in many cases to use
names instead of the objects themselves, and because names are
available for everything in AMX.
>
> > 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