Mark, 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 <schu...@apache.org>: >>>> Author: schultz >>>> Date: Thu Sep 6 15:08:58 2012 >>>> New Revision: 1381635 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=1381635&view=rev >>>> 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/JMXProxyServlet.java >>>> 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 JMXProxyServlet. Perhaps a separate servlet with an explicitly-different interface is more appropriate. -chris
signature.asc
Description: OpenPGP digital signature
