https://bz.apache.org/bugzilla/show_bug.cgi?id=65265
Bug ID: 65265
Summary: getVMInfo() in Diagnostics.java throws exceptions on
jdk > 8
Product: Tomcat 10
Version: 10.0.4
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Util
Assignee: dev@tomcat.apache.org
Reporter: ja...@kotfu.net
Target Milestone: ------
I believe I have discovered a bug in the vminfo command of the Manager
application.
Environment:
- Ubuntu 20.04.02 LTS
- Openjdk-11
- Tomcat 10.0.4 downloaded directly from
https://tomcat.apache.org/download-10.cgi (i.e. not installed from via the
operating system package manager)
Steps to reproduce:
- Load http://localhost:8080/manager/text/vminfo in your browser
Expected result: big page of info about the jvm.
Actual result: HTTP Status code 500, with one line of text “OK - VM info”.
Log output:
25-Mar-2021 14:49:41.042 SEVERE [http-nio-8080-exec-4]
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for
servlet [Manager] in context with path [/manager] threw exception
java.lang.UnsupportedOperationException: Boot class path mechanism is
not
supported
at
java.management/sun.management.RuntimeImpl.getBootClassPath(RuntimeImpl.java:99)
at org.apache.tomcat.util.Diagnostics.getVMInfo(Diagnostics.java:562)
at org.apache.tomcat.util.Diagnostics.getVMInfo(Diagnostics.java:480)
at org.apache.catalina.manager.ManagerServlet.vmInfo(ManagerServlet.java:616)
at org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:387)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:663)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:770)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:223)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
at
org.apache.catalina.filters.HttpHeaderSecurityFilter.doFilter(HttpHeaderSecurityFilter.java:126)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:668)
at
org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:378)
at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:56)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:353)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:374)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:870)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1696)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:832)
After some research, I believe I understand the root cause of this problem.
Many
jdk > 8 do not implement getBootClassPath(). If I follow the same steps to
reproduce but use openjdk 8, the vminfo command works as expected.
As the log indicates, the exception is raised by the getVMInfo() method in
Diagnostics.java
(https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/util/Diagnostics.java).
I think the solution is to guard the runtimeMXBean.getBootClassPath() method
call with a check that runtimeMXBean.isBootClassPathSupported() is true.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
