Kohsuke
Responses inline. Thank you for your persistence.
Lloyd Chambers
Sun AppServer Group
On Jul 20, 2006, at 5:08 PM, Kohsuke Kawaguchi wrote:
>
> 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.)
Yes, do use JSR 88 to deploy. We are aware of the awkward "switch"
between JSR 88 and AMX and we do plan to do something about it.
There can be many http listeners. You need to get the
Map<String,HTTPListenerConfig> via:
String configName = "server-config"; // for Glassfish default
final ConfigConfig config = domainRoot.getDomainConfig
().getConfigConfigMap().get( configName );
Map<String,HTTPListenerConfig> listeners = config.getHTTPServiceConfig
().getHTTPListenerConfigMap();
for( final HTTPListenerConfig listener : listeners ) {
System.out.println( listener.getName() + ": " +
(listener.getEnabled() ? "enabled" : "disabled") );
System.out.println( listener.getname() + " port: " + getPort();
}
Unless you've created more listeners, there is generally one http
port and one http port with SSL enabled. In Glassfish, the port
should be a number; in the Enterprise Edition it could be $
{HTTP_LISTENER_PORT}, and it would need to be resolved to an actual
number, which depends on the particular instance.
>
> 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.)
No other API in AMX. The deployment team has decided that JSR 88 is
their preferred approach to deploying and undeploying.
>
>
>> 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.
I don't agree with the characterization that "JMX tie your hands".
RMI would have been no better, in fact JMX uses the RMI-based
connector. Any remote API has limitations, particularly the
inability to serialize non-serializable and/or objects tied in some
way to the local machine.
Yes, there is room for higher level APIs, some such code is in
com.sun.appserv.management.helper packages.
>
> 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.
I was referring *only* to the DeploymentMgr.
If you feel there are other tasks which belong *in the API*, as
opposed to sample code and/or utility code which is layered on top of
the API, please send those comments along and I'll provide the
examples for starters, and see where the best place to add them might
be.
>
> In any case, I was just trying to report back one user's experience.
Thank you!!! Keep it up. :)
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems kohsuke.kawaguchi_at_sun.com