Comments inline.
> 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().
Yes, there are a few such cases. The DeploymentMgr was written as a
low-level API. The decision was made to not enhance it with such
things, and will be deprecated in 9.1.
Further, it was designed for use via straight JMX (without use of
proxies) in addition to use via proxies. A WebModule can't be passed
over the wire, only a web module name. Doubling up the methods to
have 2 variants would have bulked up the API.
>
> 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!)
The module ID is obtained via getName().
DeplomentMgr.undeploy( webModule.getName(), ... );
Again, the DeploymentMgr was never designed as a high-level API. It
was designed as a low-level API which could be thoroughly tested, and
upon which higher-level, simpler functionality could be built.
>
> 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[].
Again, low-level API. It has to exist somewhere, as bytes need to go
over the wire!
Do you have other examples besides the DeploymentMgr? It is rather
unique.
>
> 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.
Please don't judge the entire API by one low-level API for which
higher-level layering had been planned. An alternate decision was
made to refocus on JSR 88 and so this higher-level layering did not
occur.
Furthermore, design goals of allowing straight JMX (no proxies), as
well as the reality of remote access mandate a low-level means to
transport bytes, etc. Those goals cannot be met by means other than
low-level, explicit calls; one cannot serialize an InputStream acros
the wire.