배포하는 동안 "열망하는"CDI 빈이 왜 멈추는가?

Question

최근에 JSF2를 사용하는 것으로부터 CDI/weld로 전환했습니다. 나는 2 명의 열정적 인 @ManagedBeans (eager = true) 중 하나가 데이터베이스 쿼리 (JPA 2)를 사용하여 채워지는 목록을 가지고있다. 그것은 잘 작동했습니다.

나는 http://ovaraksin.blogspot.com/2013/02/eager-cdi-beans.html에 설명 된 기술을 사용하여 CDI로 전환하고 리 콩코드했습니다. 그것은 @PostConstruct init() 중에 수동으로 채워지는 bean을 위해 훌륭하게 작동하지만 데이터베이스 쿼리를 사용하는 서비스를 주입하기 위해 채워지는 bean에 매달린다.

너무 심하게 걸려 서버를 죽여야합니다!

왜 그 콩을 비 열심히 만드는 것보다 그 주위에 방법이 있습니까? 내가해야만한다면 콩을 "열심히"만들 수 있습니다. 나는 내가 오해하고있는 것이 궁금 할뿐입니다. 여기

가 걸려 빈이며 다시 끝날 것

OsList.java :

import java.util.ArrayList; 
import java.util.List; 

import javax.annotation.PostConstruct; 
import javax.enterprise.context.ApplicationScoped; 
import javax.inject.Inject; 
import javax.inject.Named; 

import org.jboss.logging.Logger; 

@Eager 
@ApplicationScoped 
@Named 
public class OsList { 

    Logger log = Logger.getLogger(OsList.class); 

    private List<String> osList = new ArrayList<String>(); 

    @Inject 
    OsListService osService; 

    public OsList() {} 

    @PostConstruct 
    public void init(){ 
     log.info("Creating the one and only OsList bean"); 
     osList = osService.fetchOs(); 
    } 

    public List<String> getOsList() { 
     return osList; 
    } 

    public void setOsList(List<String> osList) { 
     this.osList = osList; 
    } 

OsListService.java :

import java.util.ArrayList; 
import java.util.List; 

import javax.ejb.Stateless; 
import javax.persistence.EntityManager; 
import javax.persistence.PersistenceContext; 
import javax.persistence.TypedQuery; 
import javax.persistence.criteria.CriteriaBuilder; 
import javax.persistence.criteria.CriteriaQuery; 
import javax.persistence.criteria.Root; 

import org.jboss.logging.Logger; 

import dne.nmst.dac.model.Devices; 
import dne.nmst.dac.model.Devices_; 

@Stateless 
public class OsListService { 

    Logger log = Logger.getLogger(OsListService.class); 

    @PersistenceContext 
    EntityManager em; 

    public List<String> fetchOs() { 
     log.info("Do we ever get here?"); 
     CriteriaBuilder cb = em.getCriteriaBuilder(); 
     CriteriaQuery<String> cq = cb.createQuery(String.class); 
     Root<Devices> d = cq.from(Devices.class); 

     cq.select(d.get(Devices_.os)); 
     cq.distinct(true); 
     cq.orderBy(cb.asc(d.get(Devices_.os))); 

     TypedQuery<String> q = em.createQuery(cq); 

     List<String> iosList = new ArrayList<String>(); 
     iosList.add(""); 
     for (String s : q.getResultList()) { 
      iosList.add(s); 
     } 
     return iosList; 

    } 

로그 파일

11:14:43,569 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found ond-cdi.war in deployment directory. To trigger deployment create a file called ond-cdi.war.dodeploy 
11:14:43,590 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "ond-cdi.war" (runtime-name: "ond-cdi.war") 
11:14:45,330 INFO [org.jboss.as.jpa] (MSC service thread 1-5) JBAS011401: Read persistence.xml for ond 
11:14:45,731 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) JBAS016002: Processing weld deployment ond-cdi.war 
11:14:45,781 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-7) JNDI bindings for session bean named OsListService in deployment unit deployment "ond-cdi.war" are as follows: 

    java:global/ond-cdi/OsListService!gov.ssa.dne.nmst.service.OsListService 
    java:app/ond-cdi/OsListService!gov.ssa.dne.nmst.service.OsListService 
    java:module/OsListService!gov.ssa.dne.nmst.service.OsListService 
    java:global/ond-cdi/OsListService 
    java:app/ond-cdi/OsListService 
    java:module/OsListService 

11:14:45,781 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-7) JNDI bindings for session bean named DeviceService in deployment unit deployment "ond-cdi.war" are as follows: 

    java:global/ond-cdi/DeviceService!gov.ssa.dne.nmst.service.DeviceService 
    java:app/ond-cdi/DeviceService!gov.ssa.dne.nmst.service.DeviceService 
    java:module/DeviceService!gov.ssa.dne.nmst.service.DeviceService 
    java:global/ond-cdi/DeviceService 
    java:app/ond-cdi/DeviceService 
    java:module/DeviceService 

11:14:46,071 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) JBAS016005: Starting Services for CDI deployment: ond-cdi.war 
11:14:46,121 INFO [org.jboss.weld.Version] (MSC service thread 1-7) WELD-000900 1.1.13 (redhat) 
11:14:46,151 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016008: Starting weld service for deployment ond-cdi.war 
11:14:46,151 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 48) JBAS011402: Starting Persistence Unit Service 'ond-cdi.war#ond' 
11:14:46,281 INFO [org.hibernate.annotations.common.Version] (ServerService Thread Pool -- 48) HCANN000001: Hibernate Commons Annotations {4.0.1.Final-redhat-2} 
11:14:46,281 INFO [org.hibernate.Version] (ServerService Thread Pool -- 48) HHH000412: Hibernate Core {4.2.0.Final-redhat-1} 
11:14:46,281 INFO [org.hibernate.cfg.Environment] (ServerService Thread Pool -- 48) HHH000206: hibernate.properties not found 
11:14:46,281 INFO [org.hibernate.cfg.Environment] (ServerService Thread Pool -- 48) HHH000021: Bytecode provider name : javassist 
11:14:46,301 INFO [org.hibernate.ejb.Ejb3Configuration] (ServerService Thread Pool -- 48) HHH000204: Processing PersistenceUnitInfo [ 
    name: ond 
    ...] 
11:14:46,621 INFO [org.hibernate.service.jdbc.connections.internal.ConnectionProviderInitiator] (ServerService Thread Pool -- 48) HHH000130: Instantiating explicit connection provider: org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider 
11:14:46,842 INFO [org.hibernate.dialect.Dialect] (ServerService Thread Pool -- 48) HHH000400: Using dialect: org.hibernate.dialect.MySQLInnoDBDialect 
11:14:46,862 INFO [org.hibernate.engine.transaction.internal.TransactionFactoryInitiator] (ServerService Thread Pool -- 48) HHH000268: Transaction strategy: org.hibernate.engine.transaction.internal.jta.CMTTransactionFactory 
11:14:46,862 INFO [org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory] (ServerService Thread Pool -- 48) HHH000397: Using ASTQueryTranslatorFactory 
11:14:46,892 INFO [org.hibernate.validator.internal.util.Version] (ServerService Thread Pool -- 48) HV000001: Hibernate Validator 4.3.1.Final-redhat-1 
11:14:47,592 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-6) Solder Config XML provider starting... 
11:14:47,592 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-6) Loading XmlDocumentProvider: org.jboss.solder.config.xml.bootstrap.ResourceLoaderXmlDocumentProvider 
11:14:47,602 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-6) Reading XML file: vfs:/D:/work/software/jboss-eap-6.1/standalone/deployments/ond-cdi.war/WEB-INF/beans.xml 
11:14:47,612 INFO [org.jboss.solder.Version] (MSC service thread 1-6) Solder 3.1.1.Final (build id: 3.1.1.Final) 
11:14:48,422 INFO [gov.ssa.dne.nmst.util.OsList] (MSC service thread 1-6) Creating the one and only OsList bean 

Answer 1

하나 가능한 방법 @Startup 어노테이션이있는 Singleton-EJB를 사용하는 것이 문제의 원인이 될 수 있습니다. 문제를 실제로 해결하지 못했습니다.

import javax.ejb.Singleton; 
... 

@Singleton 
@Startup 
public class OsListService { 

    Logger log = Logger.getLogger(OsListService.class); 

    @PersistenceContext 
    EntityManager em; 

    private List<String> iosList; 

    @PostConstruct 
    public void init() { 


     this.iosList = ... //result from your query 
    } 

    public List<String> fetchOs() { 
     return this.iosList; 
    } 
} 

Answer 2

솔직히, 나는 왜 이것을 할 것인지 모르겠다. CDI의 일부는 콩이 필요 이상으로 오래 살지 않는다는 것입니다. 쉽게 마이그레이션하려면 콩에 대한 올바른 범위 (ApplicationScoped는 일반적으로 잘못된 범위 임)를 찾고 @PostConstruct 메소드에서 필요한 것을 수행하면됩니다.

내 생각에 EJB가 생성 될 때와 CDI 빈에서 주입해야 할 때와 서로를 차단할 때의 경쟁이 치열합니다. 나는 이것을 뒷받침 할 확실한 증거가 없다.