2016-01-06 19 views
5

Voglio ottenere bean dal metodo produttore per poterne leggere le proprietà. In alcuni scenari il bean è un bean EJB Singleton.injectionPoint.getBean() restituisce null se bean è un bean EJB in Java EE 7 (CDI 1.1)

Ho semplificato il mio codice per concentrarsi sul problema.

mio semplice qualificazione:

@Qualifier 
@Retention(RUNTIME) 
@Target({TYPE, METHOD, FIELD, PARAMETER}) 
public @interface InjectMe {} 

semplice produttore:

@Dependent 
public class SimpleProducer { 

    @Produces 
    @InjectMe 
    public String getInjectMe(InjectionPoint ip) { 
     // ip.getBean() returns null for some reason 
     return "ip=" + ip + ", bean=" + ip.getBean(); 
    } 
} 

EJB (Singleton):

@Singleton 
@Startup 
public class SimpleSingleton { 

    @Inject 
    @InjectMe 
    private String injectMe; 

    @PostConstruct 
    public void init() { 
     System.out.println(injectMe); 
    } 

}

Console uscita:

Info: ip = [BackedAnnotatedField] @Inject @InjectMe com.test.ejb.SimpleSingleton.injectMe privato, bean=null

Quando cambio Singleton chicco alla CDI fagioli tutto funziona bene (ip.getBean() rendimenti non nulli). Ha funzionato anche in Java EE 6 anche con il bean Singleton ma non in Java EE 7. Sto usando il server di applicazioni Glassfish 4.

Questo comportamento è specificato da qualche parte?

+0

Sembra un insetto di pesce cristallo. –

+0

@JohnAment: Non pensarlo, lo stesso comportamento per WildFly. Non posso ancora rispondere alla domanda, ma i possibili motivi potrebbero essere: 1) modifica del comportamento del modulo di scoperta dei bean (default: 'annotated'); 2) iniettare una stringa di classe (non contestuale); 3) non avendo scope dichiarati diverso da 'Dependent' –

+0

Se si chiama' ip.getMember(). GetDeclaringClass() ', si otterrà per entrambi i casi l'FQCN, questo è anche usato come esempio nel doc di InjectionPoint API e L'ho visto in un esempio di Deltaspike come una chiamata successiva dopo che 'bean' è' null'. –

risposta

1

Utilizzando

injectionPoint.getMember().getDeclaringClass() 

funziona per me in wildfly 10.1.0 e ho anche subito provato a Payara Server 4.1.1.162 #badassfish (build 116). Ho anche fatto un test sul nuovissimo Payara Server 4.1.1.164 #badassfish (build 28). Tuttavia, ho dovuto cambiare l'ambito del bean di produzione in @ApplicationScoped. L'ambito predefinito non ha funzionato. Nel mio caso, si rende ancora senso :)

Il metodo

injectionPoint.getBean().getBeanClass() 

lavorato per me nel vecchio Payara, ma non nel nuovo wildfly 10.1.0.Final e nuova Payara Server 4.1.1.164 # badassfish (build 28).

Se si guarda Payara, l'attuale versione 164 contiene Weld 2.4.0.Final e WildFly 10.1.0Final utilizza la versione 2.3.5.Final. In entrambe le versioni, il codice classico non funziona!

La conclusione è, su implementazioni CDI precedenti (Weld), funziona. In alcuni Wer più recenti (introdotti in Payara 161), il comportamento è cambiato. Non so se sia intenzionale o meno.

Tuttavia, la soluzione è quella di utilizzare

injectionPoint.getMember().getDeclaringClass() 

e annotare il fagiolo produttore con

@javax.enterprise.context.ApplicationScoped 

annotazione.

+1

Testato su weblogic 12.2.1 (CDI 1.1) e ho anche lo stesso problema. Mentre funzionava bene su weblogic 12.1.3 (CDI 1.0). Come hai detto, ho risolto il problema usando 'injectionPoint.getMember(). GetDeclaringClass()' – Rouliboy

+0

Sembra che questo sia già stato riconosciuto: https://issues.jboss.org/browse/WELD-2339 –

Problemi correlati