Migrando un proyecto heredado a Jakarta EE 8 (Maven EAR compilado en Wildly 26) Estoy luchando para que la inyección de dependencia funcione desde mi módulo Entities (empaquetado EJB) al módulo WAR, la estructura del proyecto Maven es:

 -WebApp.ear -WebApp-entities.jar -WebApp-ejb.jar -WebApp-web.war -WebApp-mobile.war -WebApp-api.war

La estructura fue creada en base al arquetipo wildfly-jakartaee8-with-tools

Mi DAO para inyectar es un bean @Stateless que usa @LocalBean sin interfaz, por ejemplo.

 @Named @LocalBean @Stateless @TransactionAttribute(TransactionAttributeType.REQUIRED) public class UserDAO extends GenericDAOBean<User,Long> { @PersistenceContext(unitName="ReadOnlyDatabase") private EntityManager readOnlyEntityManager; /** * Default constructor */ public UserDAO() { //Super call to construct AbstractDAO super(); } public User findNonDeletedByEmail(String email){ String s = "from User where email = :email and disabled = false"; Query query = this.getEntityManager().createQuery(s); query.setParameter("email", email); try{ return (User)query.getSingleResult(); }catch(NoResultException nre){ return null; }catch(Exception e){ return null; } } }

Mi bean CDI es un bean @RequestScoped estándar en el módulo WAR que intenta inyectar el DAO para realizar el inicio de sesión

 @Named @RequestScoped public class LoginBean implements Serializable { private static final long serialVersionUID = 1504441323094295359L; @Inject private SecurityContext securityContext; @Inject private UserDAO userDAO; @Inject private FacesContext facesContext; @Inject private ExternalContext externalContext; private String username, password; public void login() throws IOException { Credential credential = new UsernamePasswordCredential(username, new Password(password)); User user = userDAO.findByEmailForUserLogin(username); AuthenticationStatus status = securityContext.authenticate( getRequest(facesContext), getResponse(facesContext), AuthenticationParameters.withParams() .credential(credential)); switch (status) { case SEND_CONTINUE: facesContext.responseComplete(); break; case SEND_FAILURE: facesContext.addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, "Login failed", null)); break; case SUCCESS: facesContext.addMessage(null, new FacesMessage(FacesMessage.SEVERITY_INFO, "Login succeed", null)); externalContext.redirect(externalContext.getRequestContextPath() + "/user/home.xhtml"); break; case NOT_DONE: } } private static HttpServletResponse getResponse(FacesContext context) { return (HttpServletResponse) context .getExternalContext() .getResponse(); } private static HttpServletRequest getRequest(FacesContext context) { return (HttpServletRequest) context .getExternalContext() .getRequest(); } public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public String getPassword() { return password; } public void setPassword(String password) { this.password = password; }

}

Cuando llamo al método login() desde la página JSF, aparece el siguiente error:

 Target Unreachable, identifier 'loginBean' resolved to null: javax.el.PropertyNotFoundException

Si comento la inyección de userDAO, el método llama bien, así que sé que UserDAO está causando el problema, no hay otros errores.

En los registros de inicio del servidor, puedo ver que UserDAO está registrado correctamente, por ejemplo:

 java:global/WebApp/Web-entities/UserDAO!com.webapp.dao.beans.UserDAO java:app/Web-entities/UserDAO!com.webapp.dao.beans.UserDAO java:module/UserDAO!com.webapp.dao.beans.UserDAO java:global/WebApp/Web-entities/UserDAO java:app/Web-entities/UserDAO java:module/UserDAO

Tengo beans.xml definidos en /web-inf/beans.xml (guerra) y /meta-inf/beans.xml (jar) ambos con bean-discovery-mode="annotated"

Mi módulo EJB está incluido como una dependencia experta en WAR .pom con <scope>provided</scope>

También he intentado inyectar usando @EJB y tengo el mismo error.

ACTUALIZAR:

Descubrí que al configurar <ear-subdeployments-isolated>false</ear-subdeployments-isolated> en boss-deployment-structure.xml permite que la inyección funcione, sin embargo, esto crea problemas con dependencias que se duplican entre módulos y errores de ruta de clase, por lo que No creo que sea la solución correcta (nuestro proyecto heredado EE 6 tenía implementaciones EAR aisladas y DI funcionó bien)