On 23.10.2006, at 23:09, Mikolaj Rydzewski wrote:
Dan Baumann wrote:
Interesting. How does your webapp compare to MX4J's http adapter
(mx4j.sf.net)?
I didn't try hard, but I was unable to run mx4j and its http
adapter. So it's hard to compare with it.
http://mx4j.sourceforge.net/docs/ch05.html
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
javax.management 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.
Cheers,
Dan
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
