I believe I have discovered a bug in the vminfo command of the Manager application. I searched the archives of this list, and both open and closed bugs in Bugzilla, and didn’t find anything similar, so I thought I’d reach out here before filing a new bug report.
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. Can anyone else reproduce this? If so, I’m happy to add a bug report in bugzilla. Cheers, Jared
