Bug 65265

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.