including vaadin-cdi dependency in pom.xml is enough to make WAR undeployable. Why?

275 views Asked by At

Hello fellow "Stackers"

I noticed something very strange about the vaadin-cdi addon.

I was developing a vaadin-cdi app (using vaadin for the first time) locally in a Payara server running "inside" Eclipse and everything was working fine.

But when i had a couple of views finished and wanted to test the app on our test environment the Jenkins build failed while building a docker image for the Payara server and the app.

During the Docker image build phase the Payara server is basically started, configured with a couple of asadmin calls and the WAR file is deployed, just like you would if you started a Payara server in a non-Docker environment.

Here is the Dockerfile for reference:

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"]

During the deployment phase (the asadmin line with the 'deploy' command) the deployment aborts with this 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)

To find the source of the problem i rolled back all of my vaadin related changes right to the very point before i introduced vaadin for the first time to my project. That build deploys fine.

If i then make a single change to the project by including this dependency in my pom.xml:

<dependency>
  <groupId>com.vaadin</groupId>
  <artifactId>vaadin-cdi</artifactId>
  <version>2.0.0</version>
</dependency>

the build starts failing again with the exception shown above. Keep in mind at that point there are no classes in the project that reference vaadin or vaadin-cdi in any way. the dependency is the only vaadin reference in the whole project.

I'm pretty baffled what could cause this.

The vaadin-cdi version i use is the newest one as far as i know. the transitive deltaspike dependency uses version 1.7.2. there is one newer version (1.8.0) but i'm not sure how or if i can influence which version vaadin-cdi pulls, since it is a transitive dependency inside vaadin-cdi.

I googled the exception and there are some mentions of it, but they are all from around 2014/-15 when there seemed to be an incompatability between a certain version of deltaspike and weblogic server. back then it was also mentioned that the problem was fixed in a follow up version, so I don't believe this applies to my case anymore.

I would appreciate any input or ideas how i could procede to find the root cause of this and fix it.

thanks in advance!

regards Mario

EDIT: to answer the question from the comments, yes I have a bean.xml file but it is basically empty:

<?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>
1

There are 1 answers

0
Mario Köhler On BEST ANSWER

After a long while i had to come back and try to solve this. and it turns out that it seems to be related to a "bug" in Payara when you run it inside Docker.

There are tickets for both Deltaspike and Payara that can be found here:

https://issues.apache.org/jira/browse/DELTASPIKE-1285 https://github.com/payara/Payara/issues/1893

I also documented a workaround at the Deltaspike Jira Ticket.