You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2012/10/02 11:22:39 UTC
Re: svn commit: r1381635 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/manager/JMXProxyServlet.java
webapps/docs/changelog.xml webapps/docs/manager-howto.xml
On 08/09/2012 14:37, Mark Thomas wrote:
> On 08/09/2012 11:52, Konstantin Kolinko wrote:
>> 2012/9/6 <sc...@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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1381635 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/manager/JMXProxyServlet.java
webapps/docs/changelog.xml webapps/docs/manager-howto.xml
Posted by Mark Thomas <ma...@apache.org>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1381635 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/manager/JMXProxyServlet.java
webapps/docs/changelog.xml webapps/docs/manager-howto.xml
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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 <sc...@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