tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
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 16:41:12 GMT

On 10/2/12 5:22 AM, Mark Thomas wrote:
> On 08/09/2012 14:37, Mark Thomas wrote:
>> On 08/09/2012 11:52, Konstantin Kolinko wrote:
>>> 2012/9/6  <>:
>>>> Author: schultz
>>>> Date: Thu Sep  6 15:08:58 2012
>>>> New Revision: 1381635
>>>> URL:
>>>> Log:
>>>> Added multi-op modes to JMXProxyServlet.
>>>> Modified:
>>>>     tomcat/tc7.0.x/trunk/   (props changed)
>>>>     tomcat/tc7.0.x/trunk/java/org/apache/catalina/manager/
>>>>     tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
>>>>     tomcat/tc7.0.x/trunk/webapps/docs/manager-howto.xml
>>>> Propchange: tomcat/tc7.0.x/trunk/
>>>> ------------------------------------------------------------------------------
>>>>   Merged /tomcat/trunk:r1381633
>>>> +        if(null != request.getParameter("invokeAndGet")) {
>>>> ...
>>> 1. This broke formatting of the manager-howto page.
>>> You should wrap such long samples.
>>> 2. Not a showstopper, but personally I dislike such limited solutions,
>> +1. This has the potential to get very messy, very quickly. I'm not
>> massively concerned about the current state of the code but any further
>> expansion of the list of possible combinations would be much better
>> implemented as Konstantin suggests.
> The more I think about this, the less I like it. Konstantin's proposal
> is the way this should be done.
> Given the above and the documentation issues I think this should be
> reverted in the 7.0.x branch pending further discussion and the fixing
> of the documentation issues.

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.

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. If you really think that
infinite flexibility is the right way to implement this, 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

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


View raw message