Vaadin Service Interfaces as CDI Beans
Some Vaadin service interfaces can be implemented as CDI beans. If you do this, the service interface becomes a managed bean with CDI features. In which case, there is no need to register the implementation in Vaadin.
The Vaadin CDI add-on references the following interfaces:
-
I18NProvider -
InstantiatorFactory -
SystemMessagesProvider -
ErrorHandler
To ensure the beans are recognized, they should be qualified by the @VaadinServiceEnabled annotation. This is required because it marks a bean which is used as an I18NProvider by the service. If there are any other I18NProvider beans, the one that’s also used by the service is used.
An example of this is using the @VaadinServiceEnabled annotation to qualify TestSystemMessagesProvider.
@VaadinServiceEnabled
@VaadinServiceScoped
public class TestSystemMessagesProvider
implements SystemMessagesProvider {
@Override
public SystemMessages getSystemMessages(
SystemMessagesInfo systemMessagesInfo) {
CustomizedSystemMessages messages =
new CustomizedSystemMessages();
messages.setInternalErrorMessage(
"Sorry, something went wrong :(");
return messages;
}
}
@Route
public class SampleView extends Div {
@VaadinServiceEnabled
@Inject
private TestSystemMessagesProvider messageProvider;
}The purpose of @VaadinServiceScoped is to define a context of the lifespan of the Vaadin service. It isn’t necessary for this kind of bean, but it’s recommended because other Vaadin contexts can be problematic.
For example, there’s no guarantee that an active Vaadin session or UI context exists when the add-on looks for any of these beans. It’s safe, though, to use standard CDI @Dependent and @ApplicationScoped contexts.
A55D3416-D5B7-40B9-8C4A-1454E97C92F1