-----BEGIN PGP SIGNED MESSAGE----- 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.
Agreed. > 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. Agreed. > 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). Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQa2NnAAoJEBDAHFovYFnnI4EP+gMesG0RUfFvpU1sqNcWGtLn eVAeep5jp/mvbrETuO8jhGBtVVYWtc/NP46FjAhJtnEjOS6qWdsX+0zVWLlTZ9z+ WrkzA92cfzfOWfffD7rXN5fFwXJADHbC2BRXWA6w5GLe431p49iA0u7f+YLGLJq4 SDXijUUT0ikml/gkxQgis+UHqPoy0rmzNyKidZR3LZkYWJfxY2qg8LnofomXh53H 8u7hwfwUjzQLELRCPdlEjOdJ6FHrmIlM4akr3sHtJ95Sw7f7gS+hinRqctnhVuon mql6L12Aqdxk2wvtfG8krLz7geeEefzGB0D3NFzDtvhK4W9lRoZdGHOX6zFnlMGz khShLcDT7tuiiiJdPHJgP1MvauTThY8Xhv+EdccEegtJWbUR0MDBmoF984kDtkyA 8e+PRcWbv47t6YyL3NEV0X99CxEl6XI8Jdd9lgzp1kd1xJCUnOUAg+1duXukN2VW 2Gn+xnO5ZD0ji8Ipfzv1Zv1xDYiRzT2hZ4thsoVJwzhHcFGKi9HiEFr/QpB1KOXN wOnhGyzkga4YuMX4v2EYNM0tHYliu82MdgNxX38FJYEcmZwwj6kqsTTWERCEzTo+ JvSHcUgAS8BGpshcveINKVWFU4QK/EqZmizbRPfBhDxVe8DDIxePjp2cZ+yyxh6r CyOyYjRMJvdwUv2hc9lY =GBqC -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
