Bug 65265

Summary: getVMInfo() in Diagnostics.java throws exceptions on jdk > 8
Product: Tomcat 10 Reporter: jared
Component: UtilAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P2    
Version: 10.0.4   
Target Milestone: ------   
Hardware: PC   
OS: Linux   

Description jared 2021-04-26 02:21:37 UTC
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.
Comment 1 Remy Maucherat 2021-04-26 06:48:10 UTC
I agree, isBootClassPathSupported should have been used since the exception is "normal". I'll fix that.
Comment 2 Remy Maucherat 2021-04-26 10:15:13 UTC
This will be in 10.0.6, 9.0.46 and 8.5.66.