Lloyd L Chambers wrote:
> 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.
Cool. That would be nice.
> 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();
> }
Thanks.
> 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.
I suspect this would be a bit of surprise for AMX users. Why do users
need to resolve a macro like this?
> 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.
I wasn't saying "JMX ties your hands" in terms of comparing it to other
remoting APIs. What I was trying to say is that exposing the underlying
remoting API (whether that is JMX, RMI, JAX-WS, or anything) directly as
an user-level API sounds like a mistake.
Take InputStream as the example. Not many remoting APIs let you use
InputStream directly, so it has to be turned into byte[]. That's fine.
What's not fine is that you are asking your users to do this conversion,
when it's your job, as the AMX developer, to do so. Your are exposing
the complexity that's caused by your underlying layer to your users.
That's not a good API.
There are other examples where such limitations in the remoting API
shows up in AMX. Some of which we discussed in this thread, like not
being able to pass back object references like WebModule to DeploymentMgr.
All such limitations are easily overcome by having little client-side
library on top of JMX. For example, you could take an InputStream from
users, then turn it into byte[] inside this library, then pass that to
JMX. Or your signature could take WebModule as a parameter, then take
its object name, and pass it to JMX.
As an AMX user, I already need to put a whole bunch of jars in my
classpath. So having some code to do those things on the client side
isn't going to make AMX any harder to use, for users. (It's more work
for you, as an AMX developer, for sure!)
That would allow you to expose more sensible management API (which uses
JMX as the underlying layer.) That's what I wanted to see as "the
management interface for Glassfish", and that's what I wanted to see
advertized.
Users are lazy, and they expect a good developer experience. Exposing
JMX proxy interfaces as the API just doesn't cut it.
>> 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.
From my limited exposure to AMX, the scope of tasks that it covers
seems to be adequate. It did seem to have everything I wanted. What was
not adequate was the way it was exposed to me.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com