CDI enriches the EJB specification (Session beans to be specific) by providing contextual life cycle management. Session beans are not ‘contextual’ instances in general.
If you are comfortable with CDI in general, the idea of ‘being contextual’ should be pretty clear.
Here are the valid permutations and combinations of EJB session beans and corresponding CDI scopes (Application, Session or Request)
- Stateless beans can only belong to the @Dependent scope i.e. you can either choose to use the @Dependent pseudo-scope explicitly or just flow with the @Stateless annotation in which case the CDI container will pretty much use @Dependent by default (convention).
The CDI container will not let you get away with any other annotation and the end result would be a deployment failure
- With Singleton beans, @ApplicationScoped is the only valid CDI scope (@Dependent is the default in case you do not use any other explicit CDI scope)
Again, any other scope annotation and the CDI god will crush your WAR/EAR !
- Stateful EJBs can have any scope – no restrictions whatsoever! (although I do not see too much value in using @ApplicationScoped for Stateful beans – but that’s just me! feel free to chime in case you think otherwise)
Stay safe !
Cheers 😉
Advertisements
Nice post !
LikeLike
Thanks for reading Verison. Really glad you liked it ! 🙂
LikeLike
Thanks, this post filled a gap and was exactly what I was looking for!
I’m not sure if I have understood correctly but why don’t you see any point with @Stateful combined with @ApplicationScoped? Do you mean that it’s practically the same as @Singleton (possibly combined with @ApplicationScoped)?
I made a fast experiment. I have a @ViewScoped bean injecting a service into it:
Service with just @Stateful: The service defaults to view scope.
Service with @Stateful and @ApplicationScoped: The service becomes application scoped.
So @ApplicationScoped changes things here, so why don’t you recommend that combination?
Cheers,
Patrik
LikeLike