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