I have the following code to manage two kinds of repositories. Both repository classes inherit an interface to allow reinitialization of their resources.
public interface CachingRepository
{
public void invalidateCache();
}
Global, application-scoped repo:
@Named("globalRepo")
@ApplicationScoped
public class GlobalRepository implements CachingRepository
{
private List<Category> categories;
...
@Override
public void invalidateCache()
{
categories = null;
}
...
}
Per user, session-scoped repo:
@Named("userRepo")
@SessionScoped
//@Stateful // <- NOTE HERE
public class UserRepository implements CachingRepository, Serializable
{
private List<MyFile> files;
@Override
public void invalidateCache()
{
files = null;
}
...
}
When injecting this (without @Stateful
) into the context
@Named
@ViewScoped
public class MyHandler implements Serializable
{
@Inject
private UserRepository userRepo;
...
}
it works. However, when adding @Stateful
to the UserRepository
class, deployment fails with an exception saying:
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [UserRepository] with qualifiers [@Default] at injection point [[field] @Inject private de.company.project.pack.MyHandler.userRepo]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:275)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:244)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:107)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:127)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:346)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:331)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:366)
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:83)
at org.jboss.as.weld.services.WeldService.start(WeldService.java:76)
... 5 more
Adding the name of the CDI bean like
@Inject @Named("userRepo")
private UserRepository userRepo;
results in the same exception. The only thing that works in conjunction with @Stateful
is to use the interface in the var declaration:
@Inject @Named("userRepo")
private CachingRepository userRepo;
I might need sub class functionality here however, so using CachingRepository
isn't really desired (at the moment).
Q's:
UserRepository
var should already identify which class to instantiate, shouldn't it? What's the logic to this?@Stateful
EJB annotation have such severe effects here? Why does it essentially force me into using the CachingRepository
interface in the var declaration?Note, I' using Seam 3 Faces making the @ViewScoped
become a CDI view-scoped bean, so the problem at hand is likely still CDI-only.
I had the same problem with this misleading exception...
By adding @Stateful
to UserRepository
you expose EJB methods of the CachingRepository
interface without having a no-interface view declared. Add @LocalBean
to UserRepository
to activate the no-interface view. See EJB 3.1 Specification, Section 4.9.8 "Session Bean's No-Interface View"
The bean class must designate that it exposes a no-interface view via its bean class definition or in the deployment descriptor. The following rules apply:
- ...
- If the bean exposes at least one other client view, the bean designates that it exposes a no-interface view by means of the @LocalBean annotation on the bean class or in the deployment descriptor.
- ...
I also refer to this stackoverflow answer for more information about no-interface views.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With