Tomcat 9 无法从 OpenJDK 11 启动
[英]Tomcat 9 not able to start with OpenJDK 11
问题描述
I installed Tomcat 9 with OpenJDK 11 but the Tomcat service didn't start and failed with the following error:
我使用OpenJDK 11安装了Tomcat 9 ，但 Tomcat 服务没有启动并且失败并出现以下错误：
SEVERE: A child container failed during start
java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/orion]]
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:951)
at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:831)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1432)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1422)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:944)
at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:261)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.core.StandardService.startInternal(StandardService.java:422)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:801)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Catalina.start(Catalina.java:695)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:350)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/orion]]
at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:441)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1432)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1422)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:944)
... 21 more
Caused by: org.apache.xerces.parsers.ObjectFactory$ConfigurationError: Provider org.apache.xerces.parsers.XIncludeAwareParserConfiguration could not be instantiated: java.lang.SecurityException: Sealing violation loading java.io.StringReader : Package java.io is sealed.
at org.apache.xerces.parsers.ObjectFactory.newInstance(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
at org.apache.tomcat.util.digester.Digester.getParser(Digester.java:614)
at org.apache.tomcat.util.descriptor.web.WebXmlParser.<init>(WebXmlParser.java:62)
at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1099)
at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:769)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:299)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5007)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
... 27 more
After diagnostic I found that one of the jar(xerces.jar) is creating issue, so I removed that jar from my application.诊断后，我发现其中一个 jar(xerces.jar) 正在创建问题，因此我从我的应用程序中删除了该 jar。 After that tomcat service started without any issue.之后，tomcat 服务启动没有任何问题。
But once I try to access one of my servlet it gave me below error:但是，一旦我尝试访问我的 servlet 之一，它就会出现以下错误：
INFO: Marking servlet [InfoServlet] as unavailable
Nov 25, 2019 3:33:24 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Allocate exception for servlet [InfoServlet]
java.lang.SecurityException: Sealing violation loading java.io.StringWriter : Package java.io is sealed.
at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2363)
at org.apache.catalina.loader.WebappClassLoaderBase$PrivilegedFindClassByName.run(WebappClassLoaderBase.java:156)
at org.apache.catalina.loader.WebappClassLoaderBase$PrivilegedFindClassByName.run(WebappClassLoaderBase.java:145)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:832)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1297)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1157)
at org.apache.log4j.Category.getInstance(Category.java:522)
at com.pg.orion.basic.rmiservlet.InfoServlet.<clinit>(InfoServlet.java:32)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:151)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1032)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:761)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:133)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:394)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:791)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1417)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
Best part is everything is working with Java 8 without removing anything.最好的部分是一切都与 Java 8 一起工作，而无需删除任何内容。
It looks like issue is not related to xerces.jar as it is already working with Java 8 .看起来问题与xerces.jar无关，因为它已经在使用Java 8 了。 After some research I found that经过一番研究，我发现
A sealing violation means that some classes from a sealed package were loaded from two different locations (directories or jar files).密封违规意味着密封包中的某些类是从两个不同位置（目录或 jar 文件）加载的。
A sealed package is one that essentially says "I know that all classes in this package come from a single jar file. For security reason no other location may provide classes that are in this package".密封包本质上是这样一个包：“我知道这个包中的所有类都来自一个单一的 jar 文件。出于安全原因，没有其他位置可以提供这个包中的类”。
This is not the case as everything working with Java 8 .情况并非如此，因为一切都与Java 8一起工作。 Any help will be appreciated.任何帮助将不胜感激。
After diagnostic I found that -Djava.security.manager parameter is causing the whole problem that we set additionally in service.bat while installing tomcat.诊断后我发现 -Djava.security.manager 参数导致了我们在安装 tomcat 时在 service.bat 中额外设置的整个问题。 After removing -Djava.security.manager,tomcat is working normally.去掉-Djava.security.manager后，tomcat运行正常。 However, security manager we enabled in java 8 due to security policy and now because of that tomcat it is not running in java11.但是，由于安全策略，我们在 java 8 中启用了安全管理器，现在由于该 tomcat，它不在 java11 中运行。 How to resolve this issue with security manager enable and with java 11???如何使用安全管理器启用和 java 11 解决此问题？？？
2 个解决方案
解决方案1
0 2019-11-25 12:56:49
This is pretty weird.这很奇怪。 The java.io module is part of the Java runtime. java.io模块是 Java 运行时的一部分。
The only explanation I can think of is that someone has put a copy of rt.jar 1 from an older version of Java into your webapp's WAR file, or one of the Tomcat shared libraries folder.我能想到的唯一解释是有人将旧版本 Java 中的rt.jar 1副本放入您的 webapp 的 WAR 文件或 Tomcat 共享库文件夹之一。 Since Tomcat's webapp class-loaders have the search order inverted compared with a typical Java application, that could lead to these classes being loaded from the wrong place, leading to a sealing violation.由于与典型的 Java 应用程序相比，Tomcat 的 webapp 类加载器的搜索顺序是颠倒的，这可能会导致这些类从错误的位置加载，从而导致密封违规。
1 - Or something like this. 1 - 或类似的东西。 It also could be a JAR containing a subset of the standard class libraries that have been "tweaked" for some purpose.它也可以是一个包含标准类库子集的 JAR，这些标准类库出于某种目的被“调整”过。
解决方案2
0 2020-04-07 09:41:34
what was the installation procedure followed for Tomcat 9 and Openjdk 11 Tomcat 9 和 Openjdk 11 的安装过程是怎样的
Please make sure that you point to the proper JVM.dll file because in OpenJDK 11 version not bundled with JRE.请确保您指向正确的 JVM.dll 文件，因为在 OpenJDK 11 版本中未与 JRE 捆绑。 in Tomcat properties you need to map jvm.dll present in bin/server/jvm.dll.在 Tomcat 属性中，您需要映射 bin/server/jvm.dll 中存在的 jvm.dll。
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.