Add-ons

Vaadin-CDI-integration

This page is no longer maintained #

Instead, have a look at the new Vaadin CDI tutorial.

Old Vadin CDI tutorial that is still here for historical reasons #

Vaadin CDI Integration is Vaadin 7 add-on that provides easy to use CDI (Context and Dependency Injection (JSR-299)) support for Vaadin 7 framework.

The add-on is available in Vaadin Directory

Vaadin CDI Integration manages Vaadin UI:s and Views as CDI managed beans, which allow further injection, scoping and event handling support. It's really easy to setup new Vaadin 7 project with Vaadin CDI Integration add-on.

For an example on the use of Vaadin CDI, see also this example project

Setting up the project environment #

It's important to note that in order to use CDI, you must have CDI capable application server, such as Wildfly, JBoss7, TomEE or Glassfish 3.1. Any other server will do as well if some CDI implementation such as Weld exists in the server classpath. Vaadin CDI Integration also requires container to support Servlet 3.0 spec.

  • After the new project is created, add a dependency to com.vaadin:vaadin-cdi to your project's ivy.xml or pom.xml. This also adds Apache DeltaSpike as a transitive dependency. As Vaadin CDI Integration is purely server side add-on, you do not have to recompile the widgetset.
  • If your server does not support JEE7 or CDI 1.1 and operation without beans.xml, you must have empty (0 byte) beans.xml file within your WEB-INF folder. This is what fires up the CDI and makes all the classes in your Application's war file to be able to work as managed beans.
  • To enable automatic deployment of a VaadinServlet with CDIUIProvider, remove the @WebServlet in the generated UI class (or WEB-INF/web.xml if not using @WebServlet) .

If your application server requires the web.xml file to be present, remove all Vaadin servlets and their mappings from the file. If any Vaadin servlets are explicitly configured in web.xml (e.g. to use a custom widgetset or for customizing path mappings) or using Servlet 3.0 annotations, they should inherit com.vaadin.cdi.internal.VaadinCDIServlet to enable CDI.

The end result of project configuration should look as follows:

After the project has been setup, we can modify the initial template class created by Vaadin Eclipse plugin. What we do is that we add one annotation for the type

@CDIUI("")

This annotation will work as Vaadin UI identifier. It can only be used with classes that extend com.vaadin.ui.UI and it also defines a CDI scope.

The code of your first Vaadin UI class should be as follows:

@CDIUI("")
public class ExampleCDIUI extends UI {
    @Override
    public void init(VaadinRequest request) {
        Label label = new Label("Hello Vaadin user");
        setContent(label);
    }
}

Next thing to do is to deploy the application and access it from your server's context path. You will also need to specify the name of the UI you want to access to. When an empty string is given as a parameter to the @CDIUI annotation, the UI will be accessible at the root of the context. When no parameters are given to the @CDIUI annotation, the name will be automatically generated, e.g. MyTestUI would be mapped to my-test.

The whole address for the application running in the server is in Wildfly 8.1's case:

http://localhost:8080/VaadinCDIProject/

During the deployment time, you should observe following lines from the output console or log, depending on your logging properties:

INFO 1 beans inheriting from UI discovered!
INFO Vaadin UI com.example.vaadincdiproject.ExampleCDIUI is marked as @CDIUI without context path, this UI is accessible from context root of deployment
INFO Available Vaadin UIs for CDI deployment [/ => ExampleCDIUI]

Names of the discovered UI's and their mappings are presented in Available Vaadin UIs section. If you have multiple UIs they will appear as comma separated.

In order to access the UI elsewhere under the context path, add a value parameter for the @CDIUI annotation

@CDIUI(value = "exampleUI")

This will allow you to access the UI with following address:

http://localhost:8080/VaadinCDIProject/exampleUI/

You can have only one UI marked with @CDIUI("") with an empty string as the mapping.

Once you have the UI deployed, you can further inject other managed beans into it with @Inject annotation. Currently it is not possible to inject Vaadin components as vaadin jars packages do not have beans.xml defined, but with Vaadin 7.3.1 and later, it is possible to inject your own subclasses of Vaadin components.

With these simple steps, you have your Vaadin UI as managed CDI bean in which you can use everything there is to it with CDI.

Other classes or fields can be annotated with @UIScoped to make them (and their injected contents) be injected in the scope of a UI instance for which they have been created. Injecting UIScoped beans in a background thread should only be performed in a UI.access() block.

What's important to know is that CDIUI is by default in a CDI UI scope, so everything you @Inject into Vaadin UI is within the same UI scope. This means that once UI is cleaned up all the dependent beans are also cleaned up. Also the CDI event mechanism which is limited by the scopes is bound to the UI scope in this case. All the CDI events sent from and to beans inside the scope of one UI will remain there.

There will soon be other tutorials about Vaadin and CDI integration as well as how to use Vaadin 7's Navigator API with CDI, UI and view scopes and CDI events. In the meanwhile, see this example project for some examples.

The 1.0.0.beta1 version of Vaadin CDI does not support portlet deployments out of the box. Portlet support is planned in the near future. If you want to use the add-on on a portal before official support is released, the functionality of VaadinCDIServlet and VaadinCDIServletService must be duplicated in corresponding portlet classes.

Using Vaadin CDI with Maven #

To use Vaadin CDI with Maven, first add a dependency to it:

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

Then create an empty WEB-INF/beans.xml and remove the servlet annotated with @WebServlet or WEB-INF/web.xml, or edit it as explained above.

The project can be run e.g. using WildFly or TomEE by adding the corresponding build plugin to pom.xml and then executing its run goal.

<build>
    ...
       <plugins>
            ...
            <plugin>
                <groupId>org.wildfly.plugins</groupId>
                <artifactId>wildfly-maven-plugin</artifactId>
                <version>1.0.2.Final</version>
            </plugin>
        </plugins>
</build>
mvn wildfly:run
4 Attachments
28441 Views
Average (6 Votes)
Comments
Well, I am able to run mvn tomee:run and access http://localhost:8080/tomee/ but where is deployed my application? Because it is not http://localhost:8080/artifactId
Posted on 10/8/13 9:12 AM.
Oh, I see, 'mvn clean package tomee:run' is needed.
Posted on 10/8/13 11:26 AM in reply to Lubos Racansky.
Seems to work, I can inject both Vaadin component and session bean running on Wildfly. But what is the status on this addon? Is it ever going to graduate? Feels uncomfortable running on alpha code, but cdi-injection is kindof reallyreallyreallynice :-)
Posted on 3/30/14 3:44 PM.
Is it possible to use inside a liferay portlet
Posted on 5/23/14 7:43 AM.
I can not use @Inject in view, it always throw null.
Posted on 7/10/14 5:11 PM.
alpha3 broke my sample project injecting a simple session bean - on wildfly. what's changed?

https://vaadin.com/documents/portlet_file_entry/10187/minimum-vaadin-cdi.tgz/0f498594-d9b8-4ea6-8a9d-72c68f82ab64
Posted on 8/20/14 1:25 PM.