> Markdown version of [Using CDI Beans in Vaadin Applications](https://vaadin.com/docs/v14/flow/integrations/cdi/tutorial-cdi-instantiated-beans). Section index: [llms.txt](https://vaadin.com/docs/v14/flow/llms.txt)

# Using CDI Beans in Instantiated Components

When using [Vaadin CDI](https://vaadin.com/directory/component/vaadin-cdi/), most objects instantiated by framework become managed beans. The framework uses the CDI `BeanManager` to get references to beans. This means they are fully-fledged CDI contextual instances.

The add-on looks up the CDI bean by type (component class) and `@Any`.

If the type is not found as a CDI bean - for example, because it is ambiguous or does not have a no-arg public constructor - instantiation falls back to the default Vaadin behavior, and the component is instantiated as a POJO. Dependency injection is performed after instantiation and injects still work, but other CDI features do not. The reason is that the instantiated component is not a contextual instance.

> **Note:** Methods annotated with `@PreDestroy` in `Dependent` beans instantiated by the framework are not run.

## <a id="using-router-components"></a>Using Router Components

All [route targets](https://vaadin.com/docs/v14/flow/routing/tutorial-routing-annotation.md), [router layouts](https://vaadin.com/docs/v14/flow/routing/tutorial-router-layout.md), and [exception targets](https://vaadin.com/docs/v14/flow/routing/tutorial-routing-exception-handling.md) become managed beans when the add-on is used. The components look and behave the same as without the add-on, but CDI features are available.

**Example**: Using the `@Inject` annotation on a basic route target.

```java
@Route
public class MainView extends VerticalLayout {
    @Inject
    public MainView(Greeter greeter) {
        add(new Span(greeter.sayHello()));
    }
}
```

> **Note:** Vaadin scans for router components on startup and is unaware of CDI beans. Using producers or the `@Typed` annotation causes issues with this kind of bean.

## <a id="using-components-injected-into-polymer-templates"></a>Using Components Injected into Polymer Templates

Components injected into [Polymer template classes](https://vaadin.com/docs/v14/flow/templates/polymer-templates/tutorial-template-basic.md) using the `@id` annotation become managed beans when the add-on is used.

**Example**: Using the `@Id` annotation to inject the `DependentLabel` component into `TestTemplate` class.

```java
public class TestTemplate
        extends PolymerTemplate<TemplateModel> {
    @Id
    private DependentLabel label;
}
```

**Example**: `DependentLabel` class.

```java
@Dependent
@Tag("dependent-label")
public class DependentLabel extends Label {
    @Inject
    private Greeter greeter;

    @PostConstruct
    private void init() {
        setText(greeter.sayHello());
    }
}
```

**Example**: `TestTemplate.html` Polymer template.

```js
import {PolymerElement,html} from
        '@polymer/polymer/polymer-element.js';

class TestTemplate extends Polymer.Element {
    static get template() {
        return html`
            <div>
                <dependent-label id="label"/>
            </div>`;
    }

    static get is() { return 'test-template' }
}
customElements.define(TestTemplate.is, TestTemplate);
```

> **Important:** The managed bean injected into the template should not exist before the template is instantiated. If it does exist at this time, it may not bind to its element, and this may result in an incorrect component tree.

## <a id="using-a-custom-ui"></a>Using a Custom UI

It is not necessary to define a custom `UI` subclass for your application, but it is possible to define one using the corresponding servlet parameter, if needed.

The custom `UI` subclass is instantiated by Vaadin as a POJO (not as a managed bean), but it is still possible to achieve dependency injection. Use `BeanManager` in your overridden `UI.init` method, for example `BeanProvider.injectFields(this)` (in Deltaspike).

`B34832D7-4EEB-4233-BAFE-4F1FE22AC01E`