tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Baumann <>
Subject Re: Jmx-console for Tomcat
Date Tue, 24 Oct 2006 10:48:22 GMT
On 23.10.2006, at 23:09, Mikolaj Rydzewski wrote:
> Dan Baumann wrote:
>> Interesting. How does your webapp compare to MX4J's http adapter  
>> (
> I didn't try hard, but I was unable to run mx4j and its http  
> adapter. So it's hard to compare with it.
> It seems that this adapter runs its own, very simple, http server.  
> One has to write a code to start it. Am I right?

That's correct, and it's the one thing I don't like about MX4J, since  
it requires an additional port to be opened in the firewall.

The rest is pretty slick though: MX4J defines a set of commands that  
can be invoked via http, and results are served as XML. The HTML  
frontend is actually just a XSLT stylesheet that post-processes the  
XML result, and you can register custom XSLT stylesheets easily.

Insofar, MX4J's http adapter is not only a HTML frontend, but can  
also be used for integration very well (where other apps consume the  
XML, e.g. for monitoring).

> So comparing to above, my app is much easier to run. Just deploy  
> war file. It is 'just' a presentation (struts/jsp) layer over plain  
> API. But sure, I could consider using mx4j to  
> enhance it.

Granted, deploying a war file is dead simple. Personally, I'm using a  
simple spring-based webapp just to start up the MX4J http adapter (on  
a different port).

My preferred solution would be MX4J behind a servlet, so I could get  
rid of using the extra port. I've looked at the MX4J sources shortly,  
but it seems quite a bit of work. Another option would be a proxy  
servlet which talks to MX4J's web server internally, but could be  
accessed through the standard Tomcat port.


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message