tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r1381635 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/manager/ webapps/docs/changelog.xml webapps/docs/manager-howto.xml
Date Tue, 02 Oct 2012 21:57:59 GMT
Hash: SHA1

On 02/10/2012 17:41, Christopher Schultz wrote:
> Yes, the code will become convoluted if we support more varieties
> of operations but I figured that get/set or set/get (or invoke
> replacing get or set in any of those) were by far to be the most
> likely paired-operations to be performed.


> The JMXProxyServlet is designed to issue a single command (get,
> set, invoke) and return the results. I wanted to give a user the
> ability to do things like get stats and then reset them (nearly)
> simultaneously so you can get the best metrics possible.

The best metrics possible would require the two operations to be
atomic. That raises a number of questions:
- - What is the difference in results for the current approach, your
proposed approach and an atomic approach
- - Do any of these differences matter?

My instinct is that the answers are "Not much" and "No". Of course, my
instincts could be wrong (it wouldn't be the first time). Can you
expand on what prompted you to add these?

> Being able to execute multiple gets, etc. will give you a whole
> bunch of output that a client will have to parse. I think this use
> case is better-served by a real JMX client and not the
> JMXProxyServlet.


> I want to be able to to get/set and get/invoke.

Can you expand on why?

> If you really think that infinite flexibility is the right way to
> implement this,

Right now, I don't know. I am afraid that the API could grow like
topsy to accommodate different requirements. If there is a risk it
will grow, I'd prefer to have the generic solution from the start.

I think some discussion around the requirements that prompted this
should give us an idea of how likely additional expansion is. If there
is low likelihood of further expansion then your proposal looks good.
If there is a high likelihood of further expansion then I think we
need something (I have no strong views on what) more generic.

> I'll do it, but I don't like Konstantin's suggestion at all. I
> think if we want to support infinite flexibility, HTTP GET is the
> wrong approach, and an HTTP POST with an XML body is more
> appropriate to support argument association, etc. That doesn't
> fit-in with the existing interface to the JMXProxyServlet.

Fair point - although XML is usually very verbose.

> Perhaps a separate servlet with an explicitly-different interface
> is more appropriate.

Probably (if the discussion indicates a generic interface is required).


Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message