Thanks. It sounds like the bottom line is that my expectation and AMX is
bit different. So maybe I should explain why I ended up looking at AMX.
What I'm ultimately trying to do is to programatically control Glassfish
from my program (for the purpose of testing the JAX-WS RI.) I sent an
e-mail to this alias earlier (search for "Programatically control
glassfish?" thread in the archive), and people kindly sent me a few
leads that I should investigate.
So I started by looking at JSR-88, since one of the things we wanted to
do was to deploy and undeploy applications. This worked fine, but then I
realized I needed to do a few more things. One of those was to identify
the HTTP port number (so that I can access the application that I just
deployed via HTTP.)
JSR-88 didn't offer this, and since I'm really not that interested in
making this portable, I thought perhaps I should look at some Glassfish
specific management interfaces. The assumption was that usually a
portable API layer is harder to use (because it's more abstract) than
the custom container-specific API.
And of the leads people gave me (JSR-88, JSR-77, and AMX), AMX looked
like the one that fits this profile, so that's why I tried it. I could
have missed the warning sign somewhere that said this is a low-level API
not meant for outside developers.
Lloyd L Chambers wrote:
> Do you have other examples besides the DeploymentMgr? It is rather
> unique.
I was looking at how to deploy/undeploy via AMX (and finding out the TCP
port), so I'm not looking at any other parts of AMX. I didn't know
DeploymentMgr was unique --- that was the first one I looked at.
> 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.
OK. So just to make sure, there is no other API than this "low-level
API" in "the entire API", right (perhaps module JSR-88/77.)
> 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.
As I wrote, I can understand that remoting via JMX tie your hands when
designing the lower level API, but if that's the case, it would have
been nice if it's not advertised to the developer audience outside, and
instead there should have been a wrapper library for exposing the same
capabilities in more sensible API.
But then, I think you are saying that that was indeed the initial goal,
but resourcing issue forced you to change the plan, so I guess there's
nothing that can be helped there. Thank you very much for the explanation.
In any case, I was just trying to report back one user's experience.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com