Two Vaadin-CDI applications in the same EAR file

Flow
1

Hi everybody,

We are developing a JEE project consisting on a few ejb-jars and a couple of wars (both Vaadin applications using Vaadin-CDI addon) all packed in an ear file.

We can successfully deploy the ear file when only one of those applications is present, in which case the application works as expected. The problem comes when we try to have both deployed at the same time within the same ear file. We get:


SEVERE: java.lang.IllegalStateException: No bean store container bound for session
	at com.vaadin.cdi.internal.UIScopedContext.getSessionBoundBeanStoreContainer(UIScopedContext.java:123)
	at com.vaadin.cdi.internal.UIScopedContext.get(UIScopedContext.java:70)
	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:637)
	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:664)
	at com.vaadin.cdi.CDIUIProvider.createInstance(CDIUIProvider.java:64)
	at com.vaadin.server.communication.UIInitHandler.getBrowserDetailsUI(UIInitHandler.java:200)
	at com.vaadin.server.communication.UIInitHandler.synchronizedHandleRequest(UIInitHandler.java:73)
	at com.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:37)
	at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1329)
	at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:236)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
	at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
	at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
	at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
	at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
	at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
	at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
	at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
	at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
	at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
	at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
	at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
	at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
	at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
	at java.lang.Thread.run(Thread.java:679)

We have added other war applications (non Vaadin based) and they don’t cause any trouble at all so I guess we must be configuring something wrong.

Any ideas?

Many thanks!

2

Daniel,

For what it’s worth, I am having the exact same problem. I have two Vaadin 7.1.x applications annotated to use CDI (using vaadin-cdi-1.0.0.alpha1), and cannot deploy an EAR containing more than one Vaadin CDI app.

I’ve tried a number of things, including moving Vaadin jars around within the EAR (between sharing them between the two WARs, and duplicated within each WAR and not in the EAR lib), and cannot seem to get the two apps to deploy at the same time. I’ve been getting the same exception as you posted.

It “feels” like a classloading issue, but unfortunately I don’t have any better information to pass along yet.

      Matt
3

Perhaps we’re experiencing this problem, which might me related to a deficiency in the CDI spec?

https://code.google.com/p/omnifaces/wiki/KnownIssuesCDI

Summary:

“In a nutshell, a CDI extension which is enclosed in a JAR in a WAR in an EAR is not applied on a per-WAR basis, but only once on a per-EAR basis for only one WAR. This has the consequence that only one of the WARs can make use of the features offered by the CDI extension and other WARs can not. In the case of OmniFaces 1.6 this has in turn the consequence that CDI converter/validator/viewscope works in only one WAR of the EAR. In case of the CDI converter/validator it also caused a deployment failure because of an uninjectable extension in other WARs which had a variant of the infamous “WELD-001408 Unsatisfied dependencies” exception as the root cause.”

           Matt
4

BTW: While I have experienced the “No bean store container bound for session” exception, most of the time I get the following:

"Exception while loading the app : CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [CDIViewProvider]
with qualifiers [@Default]
at injection point [[BackedAnnotatedField]
… "

This is when deploying to a Glassfish 4.0.

I’d love to hear what others have to say about this, if it is a real issue, possible workarounds, etc.

Thanks!

            Matt