vaadin-cdi(-integration) not injecting EJB

Hello.

EJB injection doesn’t seem to work for me. I have two projects packaged in an EAR archive: SimPos contains my EJBs and SimPosWeb is Vaadin application. I have 0-bytes beans.xml file in WEB-INF folder of SimPosWeb. I also have vaadin-cdi-1.0-SNAPSHOT.jar library in WEB-INF/lib folder of SimPosWeb. I have only one Vaadin UI class annotated with @CDIUI annotation and I try to inject my EJB as follows:

@EJB
private SimpleCodeListsBeanLocal scl;

I have a simple button that prints out NULL or NOT NULL when clicked depending on scl being null or not null. But scl is always null. Looking at the JBoss AS 7.1.1.Final log the following lines seem interesting:

17:08:56,745 INFO [org.jboss.weld.deployer]
(MSC service thread 1-2) JBAS016002: Processing weld deployment SimPosWeb.war
17:08:56,776 INFO [org.jboss.weld.deployer]
(MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: SimPosEAR.ear
17:08:57,698 INFO [org.jboss.weld.deployer]
(MSC service thread 1-2) JBAS016008: Starting weld service for deployment SimPosEAR.ear

Also tried JBoss 7.0.2.Final, tried using @Inject… What am I doing wrong or what did I not understand correctly ?

Thanks.

David
12861.png

Found the problem: i had to change servlet class in web.xml from
com.vaadin.server.VaadinServlet
to
com.vaadin.cdi.internal.VaadinCDIServlet
. Now it works.

At least with recent snapshots, if you leave out the servlet definitions altogether (from web.xml as well as any @Servlet annotations), the ContextDeployer of the CDI add-on will automatically use the CDI servlet.

If you have servlets configured explicitly, ContextDeployer will not do this automatic servlet registration as it assumes you want to choose your own servlet class.

Yes, after I looked at the Vaadin-cdi source code I found that all out. My main problem was no helpful information in log. I have two eclipse workspaces, identical configuration and settings. And in my first workspace the only vaadin-cdi related output I was getting was:


14:29:30,539 INFO  [com.vaadin.cdi.internal.UIScopedContext]
 (MSC service thread 1-1) Instantiating UIScoped context
14:29:30,539 INFO  [com.vaadin.cdi.internal.VaadinExtension]
 (MSC service thread 1-1) UIScopedContext registered

However when I switched to my second workspace, the output I got was:


14:32:25,257 INFO  [com.vaadin.cdi.internal.UIScopedContext]
 (MSC service thread 1-2) Instantiating UIScoped context
14:32:25,257 INFO  [com.vaadin.cdi.internal.VaadinExtension]
 (MSC service thread 1-2) UIScopedContext registered
14:32:25,539 INFO  [com.vaadin.cdi.internal.ContextDeployer]
 (MSC service thread 1-1) Initializing web context for path /IbiWeb
14:32:25,539 INFO  [com.vaadin.cdi.internal.ContextDeployer]
 (MSC service thread 1-1) Discovering Vaadin UIs...
14:32:25,539 INFO  [com.vaadin.cdi.internal.ContextDeployer]
 (MSC service thread 1-1) 1 beans inheriting from UI discovered!
14:32:25,539 INFO  [com.vaadin.cdi.internal.ContextDeployer]
 (MSC service thread 1-1) Vaadin UI si.irm.ibiweb.IbiWebUI is marked as @Root, this UI is accessible from context root of deployment
14:32:25,539 INFO  [com.vaadin.cdi.internal.ContextDeployer]
 (MSC service thread 1-1) Available Vaadin UIs for CDI deployment [ibiWebUI]

14:32:25,554 WARNING [com.vaadin.cdi.internal.ContextDeployer]
 (MSC service thread 1-1) Vaadin related servlet is defined in deployment descriptor, automated deployment of VaadinCDIServlet is now disabled
14:32:25,554 INFO  [com.vaadin.cdi.internal.ContextDeployer]
 (MSC service thread 1-1) Done deploying Vaadin UIs

And that second log entries immediately point out the problem. I still don’t know why I’m getting so little information in my first workspace, but I don’t really care any more.

Thanks.

David

Are you by any chance using different application servers in those workspaces? Some of them seem not to log all information about the problems in case of such problems - I haven’t checked if they actually skip some deployment steps in that case or just some logging. At least JBoss AS and TomEE behave differently from each other.

Another possible difference in the workspaces could be the deployment assembly.

I think I figured it out. When you’re creating Vaadin 7 application in Eclipse using the Vaadin 7 Project wizard, set configuration to “Vaadin 7, Java 6, Servlet 3.0” and:

  • click Finish on the first page of the wizard, the wizard will create wrong version of web.xml. It will create version 2.4 instead of 3.0. The Dynamic Web Module facet in project options will however show version 3.0.
  • if you navigate the wizard to page 3 and check “Generate web.xml deployment descriptor” and click finish on that page, then the wizard will create the right version (3.0) of web.xml. Although that also created a wrong version (2.4 instead of 3.0) a few times.

Now, when your web.xml is 2.4, server (or better JBoss 7.1.1.Final and JBoss 7.0.2.Final) log will not contain some important information, like I mentioned in my previous post. When your web.xml is 3.0, log will contain all the information.

David

Please
create a ticket
about this so that it might get fixed for a future version of the Eclipse plug-in.

Most of the logic in the wizard comes from Eclipse WTP so the bug might be there, but it is also possible that our plug-in gives it an incorrect configuration so that should be checked at least.