Thanks guys. I will file a new bug with the details you provided about it
exposing too many get methods.
--
View this message in context:
http://tomcat.10.n6.nabble.com/What-is-the-best-way-to-view-Tomcat-JDBC-pool-properties-in-Tomcat-7-tp4557182p4559731.html
Sent from the Tomcat - User mailing
Well the exact same Spring code doesn't throw an exception with 6.0.29
version of Tomcat.
I have already entered a bug
https://issues.apache.org/bugzilla/show_bug.cgi?id=52842 for similar
exceptions thrown with version 7 that didn't exist in 6.
I didn't use XA previously and I don't need it now s
Yes you are correct we are creating the pool in Spring configuration as it is
more natural for our application, but the only problem we see now is once we
upgraded to 7.0.26 we see the following exception in the logs when viewing
through JMXProxy. The data is retrieved correctly so the exception i
In 6.0.29 we used the Spring MBeanExporter to export the Tomcat JDBC pool
properties.
We are still able to view them with this approach in JConsole and using the
JMXProxy Servlet with Tomcat 7.
However since Tomcat JDBC pool is part of Tomcat 7 are its properties
exposed without using the Spr
This appears to be another variant of the following bug that was supposed to
be fixed in 7.0.26.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52591
--
View this message in context:
http://tomcat.10.n6.nabble.com/Problem-with-JMXProxy-after-upgrading-from-6-0-29-to-7-0-26-tp4551753p4551993
Hi,
We have been using the following two JMXProxy URLs for monitoring without
issue in 6.0.29.
http://localhost:8080/manager/jmxproxy/?qry=*:type=Executor,name=tomcatThreadPool
OK - Number of results: 1
Name: Catalina:type=Executor,name=tomcatThreadPool
modelerType: org.apache.tomcat.util.
