I'm playing with Vaadin and would like to use CDI with it. However, I've run into a problem which makes me think I'm not understanding something fully.
In Vaadin (and most similar frameworks) you define an
application class that, when provided by a Servlet, provides the starting point for the application.
When the Vaadin application class is scoped (i.e. @SessionScoped) @Inject works and I can use CDI to @Inject beans into it. However, none of the other UI classes that I write (panels, etc.) seem to work with @Inject - the @Injected items are just null (I'm testing by using the security beans, Identity and Credentials.) Is there a way to get these other UI classes recognized so that I can @Inject into them?
Thanks for any help,
I looked at those and used them to get started but they only show how to get the Application class annotated. They don't show annotating any other UI classes. The forums also mention has this is currently an issue with CDI and suggest accessing all context beans through the application class. I'm wondering why it has to be that way and you can't just @Inject into UI classes directly.
... I saw this post and decided to answer my experience.
Since Vaadin is processed inside a Servlet, if you follow SEAM instructions to context management for custom servlets, everything will work fine:
1. Declare the seam filter in the web.xml
<filter> <filter-name>Seam Filter</filter-name> <filter-class>org.jboss.seam.servlet.SeamFilter</filter-class> </filter> <filter-mapping> <filter-name>Seam Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
2. Declare your Vaadin application Servlet (as described in Vaadin book)
3. in components.xml, enable the context filter
4. Inside Vaadin servlet, use SEAM API, like Component and Contexts classes
For me it's working perfectly.
For CDI, you can also use the method described in the Vaadin wiki :
(Option 2: Use CDI)
That methods subclasses the Vaadin servlet so it's initialized by CDI using @SessionScoped, as well as getting your Vaadin application via @Inject)
I'm not sure which one is better architecturally, but that method has no dependency on Seam or any other third-party library at all.