2017-12-13 3 views
0

Ich habe eine sehr einfache Anwendung geschrieben, aber CDI funktioniert nicht wie erwartet:Wildfly 11: CDI funktioniert nicht

die Definition

@EJB private CustomerProviderSessionBeanLocal customerProvider; 

nicht auf eine Instanz der Bohne führen.

Definition meiner Stateless Session Bean

@Local 
public interface CustomerProviderSessionBeanLocal { ... } 

@Stateless 
@EJB(name="ejb/CustomerProvider", beanInterface = CustomerProviderSessionBeanLocal.class, beanName = "CustomerProviderSessionBean") 
public class CustomerProviderSessionBean implements 
CustomerProviderSessionBeanLocal ... 

Controller-Bean (für JSF):

@SessionScoped @ManagedBean 
public class BackingBean { 
    @EJB private CustomerProviderSessionBeanLocal customerProvider; 

JBoss liefert:

java:global/2017_JEE_App_1_war_exploded/CustomerProviderSessionBean!beans.CustomerProviderSessionBeanLocal

java:app/2017_JEE_App_1_war_exploded/CustomerProviderSessionBean!beans.CustomerProviderSessionBeanLocal 
java:module/CustomerProviderSessionBean!beans.CustomerProviderSessionBeanLocal 
java:global/2017_JEE_App_1_war_exploded/CustomerProviderSessionBean 
java:app/2017_JEE_App_1_war_exploded/CustomerProviderSessionBean 
java:module/CustomerProviderSessionBean 

Noch Das Attribut customerProvider ist nicht initialisiert. Der Konstruktor wurde aufgerufen (kann in der Log-Datei eingesehen werden). Ich habe mehrere Varianten ausprobiert (mit/ohne Namen, lokale Schnittstelle, etc.). Mit JNDI-Lookup funktioniert:

initialContext = new InitialContext(); 
Object o = initialContext.lookup("java:app/2017_JEE_App_1_war_exploded/CustomerProviderSessionBean"); 

Mit dem gleichen JNDI-Namen in der @ EJB-Annotation nicht

Ich habe nicht die Wildfly Konfiguration geändert funktioniert!

Kann jemand helfen?

+0

Wenn Sie Ihre bckingBean-Instanz von "new BackingBean()" erstellt haben, wird CDI nicht funktionieren. Hast du? –

+0

Die Backing-Bean-Instanz wird automatisch über JSF-Zugriff erstellt.

+4

Sie mischen EJB und CDI ziemlich wild. Erstens muss eine CDI-Bean ('@SessionScoped BackingBean' in Ihrem Fall) nicht' @ ManagedBean' sein. Zweitens, versuchen Sie '@ Inject' anstelle von '@ EJB', wenn Sie möchten, dass CDI den Job ausführt (in dieser' @ SessionScoped' Bean). – Siliarus

Antwort

-1

Es sieht so aus, als ob Ihr JSF-Controller das JSF-Managed-Bean-Feature anstelle von CDI verwendet. In diesem Fall funktioniert @EJB nicht korrekt. Sie sollten Ihre Klasse wie folgt deklarieren:

@javax.inject.Named 
@javax.enterprise.context.SessionScoped 
public class BackingBean { 

    @EJB 
    private CustomerProviderSessionBeanLocal customerProvider; 

} 
+0

* "In diesem Fall wird @EJB nicht korrekt funktionieren" * Diese Aussage ist nicht wahr. '@ EJB' hat seit jeher gut in JSF native' @ ManagedBean' funktioniert. Das einzige, was nicht funktioniert, ist '@ Inject', aber OP benutzt das überhaupt nicht. Das Problem von OP ist an anderer Stelle in den bisher zur Verfügung gestellten Informationen nicht sichtbar. Meine Vermutung wäre, dass OP tatsächlich versucht, auf die EJB-Instanz innerhalb des Konstruktors von bohnen anstatt auf "@ PostConstruct" zuzugreifen. Selbst die Migration auf CDI wird das nicht lösen. – BalusC

+0

Danke für die Klarstellung. Das war mir nicht bewusst. – chkal

Verwandte Themen