Kohsuke,
Thanks for the detailed feedback. I'll be replying with several
responses to keep things from getting unwieldy.
Lloyd Chambers
Appserver team
Sun Microsystems
On Jul 20, 2006, at 1:39 PM, Kohsuke Kawaguchi wrote:
>
> I did a bit of experiment with AMX to see if I can use it for
> automating JAX-WS tests. I found a few things about AMX while this
> exercise, so I thought I'd send it here to see if the glassfish
> developers are interested in fixing those.
>
> 1. This webpage https://glassfish.dev.java.net/javaee5/amx/ is great,
> but it has a few things to be desired.
>
> - it has a link to the sample code javadoc, but it's more
> appropriate
> to link to the sample source code in FishEye, or better yet, a
> downloadable sample bundle. There really isn't much point in
> seeing
> the *javadoc* of the sample --- I want to see the code!
> (I still haven't found where the sample source files are in the
> repository.)
>
> - There are things that are only linked from the "news" section.
> I thought the way news works is that you add something to the main
> page (the rest of the page), and then *also* put that to the news
> section to highlight it. I find it confusing when something is
> only
> available in the news, because as the first-time visitor to the
> website, I thought I didn't need to read any news.
>
> 2. The way AMX uses Generics is just horrible. It's not uncommon to
> see signatures like:
>
> <T extends J2EEResource> Set<T> getResourcesSet();
>
> (this one is in J2EEServer), which is probably supposed to be
> either:
>
> Set<J2EEResource> getResourceSet()
>
> or:
>
> <T extends J2EEResource> Set<T> getResourceSet(Class<T> type);
>
> Another example is:
>
> <T1 extends Serializable,T2 extends Serializable>
> void startDeploy(Object deployID,
> Map<String,T1> source,
> Map<String,T2> plan,
> Map<String,String> options)
>
> ... which should have been just:
>
> void startDeploy(Object deployID,
> Map<String,? extends Serializable> source,
> Map<String,? extends Serializable> plan,
> Map<String,String> options)
>
> I really hope this is corrected.
>
>
> 3. The whole interfaces are not object-oriented. For example, it's
> relatively straight-forward to realize that 'WebModule' interface
> represents a web module, but how do I undeploy this? I'd expect
> WebModule.undeploy() (or to be more precise, probably
> J2EEDeployedObject.undeploy() --- WebModule inherits
> J2EEdeployedObject) but there's no such method. Instead, I'm
> guessing
> I'd have to use DeploymentMgr.undeploy().
>
> To make it even worse, DeploymentMgr.undeploy() doesn't take
> J2EEDepoyedObject. It takes the module ID (but I don't see any
> getModuleID() method on WebModule!)
>
> I'm sure this separation between objects that represent the domain
> model (such as J2EEDeployedcbject) and objects that acts on them
> (such as ***Mgr) made sense from the Appserver implementation PoV,
> but it just ends up making the API harder for use for users.
>
>
> 4. Some of the APIs are kinda clumsy, perhaps due to the JMX
> limitations. For example, DeploymentMgr.uploadBytes(Object,byte[])
> is a method that uploads a file, but it should really take
> InputStream, not byte[].
>
> If JMX is forcing you to make the API uglier, that makes me
> wonder if
> AMX should have a thin wrapper on the client-side to handle those
> differences and provide a better API.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems kohsuke.kawaguchi_at_sun.com