2012-10-31 13 views
6

Sto lottando un po 'per mettere insieme quello che pensavo fosse un compito semplice. Ho un fagiolo stateless Singleton, che userò come "caricatore" per la mia app. Il bean è incluso in un file Jar (loader.jar) e risiede nella cartella lib del mio EAR.Iniezione di un Logger in un EJB tramite CDI

Nella radice di EAR si trova un altro contenitore contenente l'implementazione di un bean di sessione stateless che verrà utilizzato dalla mia applicazione.

Poi ho creato una piccola classe logger, che in realtà avvolge log4j:



    import javax.annotation.PostConstruct; 
    import javax.annotation.PreDestroy; 
    import javax.enterprise.context.RequestScoped; 
    import javax.enterprise.inject.Produces; 
    import javax.enterprise.inject.spi.InjectionPoint; 
    import javax.inject.Named; 

    import org.apache.log4j.Logger; 

    public class LoggerFactory { 
     private Logger logger; 

     public LoggerFactory(){ 
      logger = Logger.getLogger(this.getClass().getName()); 
     } 

     @Produces Logger getLogger(InjectionPoint caller){ 
      return Logger.getLogger(caller.getMember().getDeclaringClass().getName()); 
     } 
    } 

Poi ho messo questo all'interno di un barattolo, che ho nominato come utils.jar. In questo jar, seguendo le specifiche del CDI, ho creato all'interno della cartella META-INF un file beans.xml vuoto. Il file utils.jar si trova nella cartella lib del mio EAR.

Ora, nel apolidi Singleton Bean ho accennato prima (il caricatore)

ho scritto proprio questo



    import javax.annotation.PostConstruct; 
    import javax.ejb.Singleton; 
    import javax.ejb.Startup; 
    import javax.inject.Inject; 

    import org.apache.log4j.Logger; 

    @Startup 
    @Singleton 
    public class Core { 
     @Inject 
     private Logger logger; 

     @PostConstruct 
     void init(){ 
      logger.info("Core started"); 
     } 
    } 

quando schiero la mia applicazione su GlassFish 3.1.2 ottengo un NPE normale alla prima chiamata del logger nel mio bean Loader. Questo mi fa pensare che l'invocazione del CDI non stia accadendo affatto, ma sinceramente non capisco cosa sto sbagliando.

Finora la mia struttura dell'orecchio è la seguente:



     EAR 
     | 
     +---lib 
     |  +--loader.jar 
     |  +--utils.jar 
     |  +--log4j.xx.jar 
     | 
     +--MyStatelessSessionBean.jar 

Grazie mille per il vostro aiuto

risposta

0

Ci sono alcune incongruenze tra il testo e la struttura del vostro orecchio, cioè si parla di un utils.jar ma non c'è alcun .jar nel diagramma della struttura EAR.

Tuttavia, si menziona che il proprio @EJB è contenuto all'interno di loader.jar che a sua volta si trova nella cartella /lib del proprio EAR. Dal loader.jar è il tuo ejb-jar non dovrebbe essere sotto /lib, ma dovrebbe essere al livello più alto del tuo EAR.

Nella application.xml:

<?xml version="1.0" encoding="UTF-8"?> 
<application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_6.xsd" version="6"> 
    <module> 
     <ejb>loader.jar</ejb> 
    </module> 
    ... 
    <library-directory>lib</library-directory> 
</application> 

Speriamo che questo risolve il problema.

+0

Grazie, ho aggiornato la domanda subito. Beh, in realtà avrò due bean, un bean di sessione stateless (MyStatelessSessionBean.jar) e il mio bean stateless (loader.jar) singleton. Proverò a provare questa impostazione e a postare qui al più presto. Grazie mille per il vostro aiuto! – fabpicca

+0

Ciò che in realtà ha risolto il problema, è stato il confezionamento del caricatore in un'app Web dinamica (spostandola quindi a livello di root EAR) e lasciando la mia lib utils.jar nella cartella EAR/lib. In realtà l'application.xml è opzionale e, per il momento, mi piacerebbe lasciarlo per semplicità. Proverò a creare un caricatore impacchettato, ma per il momento proseguirò con quello imballato in una guerra. Grazie per il vostro sostegno! – fabpicca

+0

O un tipo di archivio dovrebbe funzionare e hai ragione che 'application.xml' è facoltativo. Sono contento che sia stato di aiuto. – rdcrng

Problemi correlati