Vaadin service interfaces as a CDI bean

Some Vaadin service interfaces can be implemented as a CDI bean. This way there is no need to register your implementation in the framework, and it became a managed bean with CDI features. Interfaces looked up by the add-on:

  • I18NProvider

  • Instantiator

  • SystemMessagesProvider

  • ErrorHandler

Beans have to be qualified by @VaadinServiceEnabled to be picked up.

Example of a SystemMessagesProvider:

Java

  1. @VaadinServiceEnabled
  2. @VaadinServiceScoped
  3. public class TestSystemMessagesProvider implements SystemMessagesProvider {
  4. @Override
  5. public SystemMessages getSystemMessages(SystemMessagesInfo systemMessagesInfo) {
  6. CustomizedSystemMessages messages = new CustomizedSystemMessages();
  7. messages.setInternalErrorMessage("Sorry, something went wrong :(");
  8. return messages;
  9. }
  10. }
Note
@VaadinServiceScoped context’s purpose is to define a context with the lifespan of the Vaadin Service. It is not mandatory for these kind of beans, but other Vaadin contexts likely cause issues. There is no guarantee that an active vaadin session, or ui context exists during the add-on looks up any of these beans. Standard CDI @Dependent, and @ApplicationScoped contexts are safe too.