Controlando o CDI Startup dentro do EJB 3.1

Sou novo aqui e também novo no mundo do CDI, e a primeira tarefa que consegui fazer foi descobrir uma maneira de controlar o upload do CDI.

Estamos usando o EJB 3.1 e o CDI 1.0 e, como eles são controlados por contêineres diferentes, podemos controlar quando e em que ordem o EJB Managed Beans estará @Startup usando as annotations @Singleton e @Singleton .

Mas o bean @Inject CDI que eu declarei na minha class está vindo como null, já que o CDI Container não foi iniciado ainda.

Eu tenho tentado por vários dias procurar soluções e a que eu encontrei aqui não funcionou (ainda veio como nula).

Estamos usando o Java EE 6 e executando o aplicativo no WebSphere Application Server 8.

Por favor, se você pudesse me ajudar a encontrar uma maneira de controlar o upload do CDI dentro e independentemente do EJB?

Aqui está um exemplo de código:

 import javax.annotation.PostConstruct; import javax.ejb.Singleton; import javax.ejb.Startup; @Singleton @Startup public class BaseStartupLoader{ /** * Default constructor. */ @Inject @MyStartup BaseStartUp myStartup; private static Logger m_logger = LoggerFactory.getLogger(BaseStartupLoader.class); public BaseStartupLoader() { } @PostConstruct public void init(){ String applicationName = null; try { applicationName = myStartup.getClass().getName(); myStartup.load(); } catch (IllegalAccessException e) { m_logger.error("Faild to load data into preload system. "+e); } catch (InstantiationException e) { m_logger.error("Faild to load data into preload system. "+e); } catch (ClassNotFoundException e) { m_logger.error("Faild to load data into preload system - Class "+ applicationName + "Not found. "+e); } } } 

Aqui está a Interface BaseStartup:

 public interface BaseStartUp { public void load() throws IllegalAccessException, InstantiationException, ClassNotFoundException; } 

O Qualificador e Implementação:

 @Retention(RetentionPolicy.RUNTIME) @Target ({ElementType.PARAMETER, ElementType.FIELD, ElementType.TYPE, ElementType.METHOD}) @Qualifier @Dependent public @interface MyStartup { } @MyStartup public class MyStartUpLoader implements BaseStartUp { @Inject SomeConfigLoader config; @Override public void load() throws IllegalAccessException, InstantiationException, ClassNotFoundException { conifg.init(); } } 

Depois de muita pesquisa, encontrei alguma ajuda dos caras da IBM, já que estamos trabalhando com o WebSphere Application Server, posso simplesmente adicionar uma propriedade da JVM chamada:

“com.ibm.ws.cdi.immediate.ejb.start” = verdadeiro

para o WAS no Admin Console, e ele garantirá que, assim que eu chegar ao método @PostConstruct do EJB no bean @Startup que criei, o CDI Container já esteja em execução e já tenha sido injetado.

Funciona!!

Aqui está o link para o Problema e Solução no site da IBM:

http://www-01.ibm.com/support/docview.wss?uid=swg1PM62774

Talvez verifique se o CDI está de fato habilitado em todos os lugares do aplicativo onde ele precisa estar. Tente adicionar este código ao BaseStartupLoader como uma experiência:

 @Singleton @Startup public class BaseStartupLoader { @Inject @MyStartup BaseStartUp myStartup; @Inject private InjectionTest test; public static class InjectionTest {} } 

Se a variável de test vier null no @PostConstruct , então o CDI provavelmente não estará habilitado no jar onde o BaseStartupLoader é declarado.

Por exemplo, se o BaseStartupLoader for declarado em um jar chamado orange.jar e o MyStartUpLoader for declarado em um yellow.jar chamado yellow.jar , então esses dois arquivos devem existir:

  • orange.jar!/META-INF/beans.xml
  • yellow.jar!/META-INF/beans.xml

Se o CDI estiver habilitado corretamente em ambos os jars por meio de um META-INF/beans.xml , isso é um bug no contêiner. Todos os pontos do @Inject devem ser preenchidos (para jars habilitados para CDI), antes da chamada de @PostConstruct ser chamada. Isso é verdadeiro, independentemente de se @Startup é usado e um dos beans seja um EJB.

Dê uma olhada no DeltaSpike. Há um módulo de controle CDI que deve fazer o que você está procurando agora. Eu acredito que o Java EE 7 deve consertar isso também.