Les dépendances non satisfaites de type [...] avec des qualificatifs [@Default] au point d'injection (à l'aide de @EJB Stateful avec le CDI)

J'ai le code suivant pour gérer les deux types de dépôts. Les deux classes de dépôt hériter d'une interface pour permettre la réinitialisation de leurs ressources.

public interface CachingRepository
{
    public void invalidateCache();
}

Mondiale, de portée application repo:

@Named("globalRepo")
@ApplicationScoped
public class GlobalRepository implements CachingRepository
{
    private List<Category> categories;

    ...

    @Override
    public void invalidateCache()
    {
        categories = null;
    }

    ...
}

Par l'utilisateur, session d'étendue de repo:

@Named("userRepo")
@SessionScoped
//@Stateful         //<- NOTE HERE
public class UserRepository implements CachingRepository, Serializable
{
    private List<MyFile> files;

    @Override
    public void invalidateCache()
    {
        files = null;
    }

    ...
}

Lors de l'injection de ce (sans @Stateful) dans le contexte

@Named
@ViewScoped
public class MyHandler implements Serializable
{
    @Inject
    private UserRepository userRepo;

    ...
}

il fonctionne. Cependant, lors de l'ajout d' @Stateful à la UserRepository classe, le déploiement échoue avec une exception en disant:

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

Ajoutant le nom de la CDI bean comme des

@Inject @Named("userRepo")
private UserRepository userRepo;

résultats dans la même exception. La seule chose qui fonctionne en conjonction avec @Stateful est d'utiliser l'interface dans le var déclaration:

@Inject @Named("userRepo")
private CachingRepository userRepo;

Je pourrais en avoir besoin sous-classe de la fonctionnalité ici cependant, l'utilisation d'un CachingRepository n'est pas vraiment souhaitée (pour le moment).

Q:

  1. Pourquoi n'est-ce pas fonctionne comme prévu? Le UserRepository var devrait déjà identifier la classe à instancier, n'est-ce pas? Quelle est la logique à cela?
  2. Pourquoi le @Stateful EJB annotation avoir de tels effets graves ici? Pourquoi est-il essentiellement de me forcer à l'aide de la CachingRepository interface dans le var déclaration?

Note, je' l'aide de Couture 3 Faces de faire de la @ViewScoped devenir un CDI vue d'étendue de haricot, de sorte que le problème est probablement encore CDI-seulement.

Oh, et BTW, ce semble avoir répondu à un certain degré avant ici stackoverflow.com/questions/9038815/..., mais pourquoi "si vous utilisez un EJB vous ne pouvez pas utiliser la mise en œuvre plus"? Quelle est la logique derrière cela? Pourquoi n'est il plus possible? Cette convention semble exister, mais pourquoi ne fait-il à tous?
Comme je l'ai écrit, je ne vois pas de sens, et je suis content qu'il n'est plus possible donc je ne peux pas aider avec celui-)
Etes-vous conscient que vous avez besoin @Named si et seulement si vous avez besoin d'ACI-l'accès à un CDI managed bean? Il n'est de fournir un qualifié EL-nom, il n' pas faire un pojo pour un CDI managed bean (qui est "fait" par beans.xml) ...
Oui, je le fais. 🙂 Le repos sont affichés comme des tables de données pour sélectionner des fichiers à partir de la vue étendue de haricots essentiellement fonction des gestionnaires pour les uploads de fichier/absorptions (requêtes AJAX). Dès qu'un fichier est ajouté ou supprimé, la liste de leurs pensions de fichiers doit être invalidé pour être réaffiché. Au moins, c'est l'idée courante.

OriginalL'auteur Kawu | 2012-04-27