Tengo el siguiente código para administrar dos tipos de repositorios. Ambas clases de repositorio heredan una interfaz para permitir la reinicialización de sus recursos.Dependencias insatisfechas para el tipo [...] con calificadores [@Default] en el punto de inyección (utilizando @Blanco EJB con CDI)
public interface CachingRepository
{
public void invalidateCache();
}
global, de ámbito de aplicación de recompra:
@Named("globalRepo")
@ApplicationScoped
public class GlobalRepository implements CachingRepository
{
private List<Category> categories;
...
@Override
public void invalidateCache()
{
categories = null;
}
...
}
por usuario, ámbito de sesión repo:
@Named("userRepo")
@SessionScoped
//@Stateful // <- NOTE HERE
public class UserRepository implements CachingRepository, Serializable
{
private List<MyFile> files;
@Override
public void invalidateCache()
{
files = null;
}
...
}
Al inyectar este (sin @Stateful) en el contexto
@Named
@ViewScoped
public class MyHandler implements Serializable
{
@Inject
private UserRepository userRepo;
...
}
funciona. Sin embargo, cuando se añade a la clase @StatefulUserRepository, el despliegue falla con un dicho excepción:
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
Añadir el nombre del bean CDI como
@Inject @Named("userRepo")
private UserRepository userRepo;
resultados en la misma excepción. La única cosa que funciona en conjunción con @Stateful es utilizar la interfaz en la declaración var:
@Inject @Named("userRepo")
private CachingRepository userRepo;
que podría necesitar funcionalidad subclase aquí, sin embargo, por lo que usar CachingRepository no es realmente deseada (por el momento).
de Q:
- ¿Por qué no esta funcionando como se esperaba? La var
UserRepositoryya debería identificar qué clase instanciar, ¿no es así? ¿Cuál es la lógica de esto? - ¿Por qué la anotación EJB
@Statefultiene efectos tan graves aquí? ¿Por qué básicamente me obliga a usar la interfazCachingRepositoryen la declaración var?
Nota, I' Uso de la costura 3 caras que hacen la @ViewScoped convertido en un grano de vista de ámbito de CDI, por lo que el problema en cuestión es probable que todavía CDI sólo.
Ah, y por cierto esto parece haber sido respondido hasta cierto punto antes aquí http://stackoverflow.com/questions/9038815/weld-001408-desatisfied-dependencies-when-injecting-ejbs-that-implement-interfac, pero ¿por qué "si usas un EJB ya no puedes usar la implementación"? ¿Cuál es la lógica detrás de esto? ¿Por qué ya no es posible? Esta convención parece existir, pero ¿por qué lo hace? – Kawu
Mientras escribía, no veo ningún sentido al respecto y estoy contento de que ya no sea posible, así que no puedo evitarlo-) –
¿Sabía que necesita '@ Named' si, y solo si lo necesita? Acceso JSF para un frijol administrado CDI? Todo lo que hace es proporcionar un nombre EL calificado, ** no ** hacer un pojo a un bean administrado CDI (que es 'hecho' por beans.xml) ... –