包括pom.xml中的vaadin-cdi依赖关系足以使WAR不可部署。 为什么？
你好同胞“堆垛机”
我注意到vaadin-cdi插件的一些非常奇怪的东西。
我在一个运行Eclipse内部的Payara服务器上本地开发了一个vaadin-cdi应用程序（第一次使用vaadin），一切工作正常。
但是，当我有几个意见完成，并希望testing我们的testing环境中的应用程序，Jenkins构build失败，同时build立Payara服务器和应用程序的docker图像。
在Docker映像构build阶段，Payara服务器基本上启动，configuration了几个asadmin调用，并部署了WAR文件，就像在非Docker环境中启动Payara服务器一样。
这里是Dockerfile供参考：
FROM payara/server-full COPY ./start-payara.sh / USER root RUN chmod +x /start-payara.sh USER payara COPY ./target/customerscoring-1.0-SNAPSHOT.war / COPY ./asadmin.txt / RUN /opt/payara41/bin/asadmin start-domain && \ /opt/payara41/bin/asadmin -u admin --passwordfile /asadmin.txt create-jdbc-connection-pool --datasourceclassname oracle.jdbc.pool.OracleDataSource --restype javax.sql.DataSource --property url="jdbc\\:oracle\\:thin\\:@coredevdb037.ov.otto.de\\:1521\\:COR99TS":password=noa:user=customerscoring COR99TSPool && \ /opt/payara41/bin/asadmin -u admin --passwordfile /asadmin.txt create-jdbc-resource --connectionpoolid COR99TSPool COR99TSDatasource && \ /opt/payara41/bin/asadmin -u admin --passwordfile /asadmin.txt set-log-attributes com.sun.enterprise.server.logging.GFFileHandler.rotationLimitInBytes=1073741824 && \ /opt/payara41/bin/asadmin -u admin --passwordfile /asadmin.txt set-log-attributes com.sun.enterprise.server.logging.GFFileHandler.rotationTimelimitInMinutes=1440 && \ /opt/payara41/bin/asadmin -u admin --passwordfile /asadmin.txt set-log-attributes com.sun.enterprise.server.logging.GFFileHandler.maxHistoryFiles=5 && \ /opt/payara41/bin/asadmin -u admin --passwordfile /asadmin.txt deploy --name customerscoring --contextroot / /customerscoring-1.0-SNAPSHOT.war && \ /opt/payara41/bin/asadmin stop-domain EXPOSE 8080 ENTRYPOINT ["/start-payara.sh"] 在部署阶段（带有'deploy'命令的asadmin行），部署将exception终止：
[91mremote failure: Error occurred during deployment: Exception while loading the app : CDI deployment failure:Exception List with 5 exceptions: Exception 0 : org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type DeltaSpikeContextExtension with qualifiers @Default at injection point [BackedAnnotatedField] @Inject private org.apache.deltaspike.core.impl.scope.viewaccess.ViewAccessContextArtifactProducer.deltaSpikeContextExtension at org.apache.deltaspike.core.impl.scope.viewaccess.ViewAccessContextArtifactProducer.deltaSpikeContextExtension(ViewAccessContextArtifactProducer.java:0) at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:362) at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:284) at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:137) at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:158) at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:501) at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:487) at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:462) at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:454) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90) at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:227) at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131) at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:329) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:220) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:487) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:360) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534) at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565) at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:360) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722) at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404) at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144) at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161) at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160) at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99) at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389) at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347) at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102) at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326) at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) at org.glassfish.jersey.internal.Errors.process(Errors.java:315) at org.glassfish.jersey.internal.Errors.process(Errors.java:297) at org.glassfish.jersey.internal.Errors.process(Errors.java:267) at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:384) at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173) at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179) at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:466) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:169) at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206) at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180) at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235) at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231) at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231) at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:539) at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadR[0m[91munnable.run(WorkerThreadIOStrategy.java:137) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:593) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:573) at java.lang.Thread.run(Thread.java:748)
为了find问题的根源，我把我所有的vaadin相关的变化都回滚到了第一次将vaadin引入到我的项目之前的那一刻。 该构build部署良好。
如果我然后通过在我的pom.xml中包含这个依赖关系对项目进行一个更改：
<dependency> <groupId>com.vaadin</groupId> <artifactId>vaadin-cdi</artifactId> <version>2.0.0</version> </dependency>
除了上面的例外，构build开始失败。 请记住，在这一点上，项目中没有任何以任何方式引用vaadin或vaadin-cdi的类。 依赖项是整个项目中唯一的vaadin引用。
我很困惑什么可能导致这一点。
据我所知，我使用的vaadin-cdi版本是最新的版本。 传递式deltaspike依赖使用版本1.7.2。 有一个较新的版本（1.8.0），但我不知道如何或如果我可以影响哪个版本vaadin-cdi拉，因为它是在vaadin-cdi内传递依赖。
我search了这个例外，并且提到了这个例外，但是它们都是在2014年-15年左右的时候，在某个版本的deltaspike和weblogic服务器之间似乎有一种不兼容性。 当时还提到这个问题在后续版本中已经修复，所以我不认为这适用于我的情况了。
我将不胜感激任何意见或想法如何我可以继续find这个根本原因并解决它。
提前致谢！
问候马里奥
编辑：从评论中回答问题，是的，我有一个bean.xml文件，但它基本上是空的：
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd"> </beans>
过了很久，我不得不回来尝试解决这个问题。 事实certificate，在Docker中运行它时，似乎与Payara中的“bug”有关。
可以在这里findDeltaspike和Payara的门票：
https://issues.apache.org/jira/browse/DELTASPIKE-1285 https://github.com/payara/Payara/issues/1893
我还在Deltaspike Jira Ticket上logging了一个解决方法。