Components instantiated by the framework

Most of the components instantiated by the Vaadin framework become managed beans ( full fledged CDI contextual instances ). They are queried from CDI BeanManager by the add-on, and all of the CDI features are usable.

Note
Add-on looks up the CDI bean by type ( component class ), and @Any.
Note
When type is not found as a CDI bean ( for example ambiguous, or does not have a no-arg public constructor ), instantiation falls back to the default Vaadin behavior ( instantiated as a POJO ). After the instantiation, dependency injection is performed. Injects work, but other CDI features are not, because instantiated component is not a contextual instance.
Note
@PreDestroy of @Dependent beans instantiated by the framework are not run. Since it is the default context, it is about all beans without an explicit context.

Router components ( @Route, RouteLayout, HasErrorParameter )

Your route targets, route layouts, and exception targets become managed beans. They look just the same as without the add-on, but CDI features are available.

An example of a minimal route target using @Inject:

Java

  1. @Route
  2. public class MainView extends VerticalLayout {
  3.     @Inject
  4.     public MainView(Greeter greeter) {
  5.         add(new Span(greeter.sayHello()));
  6.     }
  7. }
Note
Vaadin scans router components on startup without any clue about CDI beans. Using producers, or @Typed causes issues with these kind of beans.

Components injected by @Id into polymer templates

Components injected into polymer template classes by @id become managed beans.

For example:

Java

  1. public class TestTemplate extends PolymerTemplate<TemplateModel> {
  2.     @Id
  3.     private DependentLabel label;
  4. }

Java

  1. @Dependent
  2. @Tag("dependent-label")
  3. public class DependentLabel extends Label {
  4.     @Inject
  5.     private Greeter greeter;
  7.     @PostConstruct
  8.     private void init() {
  9.         setText(greeter.sayHello());
  10.     }
  11. }

HTML

  1. <link rel="import" href="bower_components/polymer/polymer-element.html">
  3. <dom-module id="test-template">
  4.     <template>
  5.         <div>
  6.             <dependent-label id="label"/>
  7.         </div>
  8.     </template>
  10.     <script>
  11.         class TestTemplate extends Polymer.Element {
  12.             static get is() { return 'test-template' }
  13.         }
  14.         customElements.define(TestTemplate.is, TestTemplate);
  15.     </script>
  16. </dom-module>
Important
The managed bean injected into the template should not exist before the instantiation of the template. Otherwise it doesn’t bind to it’s element causing a wrong component tree. A dependent bean is safe.

Custom UI is not a managed bean

As of Vaadin Flow no custom UI subclass is needed for the application. You can define one by the corresponding servlet parameter, but it is instantiated by the framework as a POJO.

You should not need a custom UI subclass. Though dependency injection can be achieved, just in case. Use BeanManager in your overridden UI.init. Through Deltaspike’s BeanProvider.injectFields(this) for example.