2017-02-17 2 views
0

Ich habe eine MDB, die seine MessageHandler-Implementierung über Autowiring erhalten soll. Aber bei Runtine ist dieses Objekt null. Sogar der Haltepunkt beim Setzer wurde nie erreicht. Wenn ein Haltepunkt innerhalb der onMessage-Methode der BaseMDB (die durch die folgende MDB erweitert wird) ist es erreicht, und ich kann sehen, das messageHandler-Objekt ist null. Ich bekomme dann eine Nullpointer-Ausnahme. Deshalb denke ich, dass das Autowiren nicht funktioniert.Spring Injection in MessageDrivenBean funktioniert nicht - null Zeiger - jboss eap 7

meine MDB sieht wie folgt aus:

@MessageDriven(name = "MyProjectIntern-Bean", activationConfig = { 
                   @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), 
                  @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/q_myproject_intern") }) 
@Interceptors(SpringBeanAutowiringInterceptor.class) 
public class MyprojectInternMDB extends BaseMDB implements MessageListener { 

    @Override 
    @Autowired 
    public void setMessageHandler(@Qualifier("myprojectInternalMessageHandler") MessageHandler messageHandler) { 
     this.messageHandler = messageHandler; 
    } 
} 

Wie aus Whaat ich den SpringBeanAutowiringInterceptor gelesen habe verwendet die Standard Fabrik, so dass ich die beanRefContext.xml in Klassenpfad haben muß. Es sieht aus wie folgt:

<?xml version="1.0" encoding="UTF-8"?> 
<beans xmlns="http://www.springframework.org/schema/beans" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> 
    <bean id="server.context" class="org.springframework.context.support.ClassPathXmlApplicationContext"> 
     <constructor-arg> 
      <list> 
       <value>/container-context.xml</value> 
       <value>/services-context.xml</value> 
       <value>/techcommon-context.xml</value> 
       <value>/container-services-context.xml</value> 
       <value>/container-context-timb.xml</value> 
       <value>/fxp-services-context.xml</value> 
       <value>/stm-services-context.xml</value> 
      </list> 
     </constructor-arg> 
    </bean> 
</beans> 

Beim Start der Jboss-Konsole zeigt mir auch, dass diese alle XML-Dateien aus beanRefContext.xml mit den Worten geladen werden:

Loading XML bean definitions from URL [<pathTobeanRefContext.XML][...] 

So seine correlty Ich denke, die innerhalb Classpath.

Innerhalb der Container-context.xml Theres unter anderem die folgenden Eintrag:

<context:annotation-config/> 

Innerhalb der Container-Dienste-context.xml Theres unter anderem die folgende Zeile ein:

<bean id="internalMessageHandler" class="com.myproject.server.message.InternalMessageHandler"> 
    <qualifier value="myprojectInternalMessageHandler" /> 
</bean> 

Also meine MDB hat einen Intercepter, der den messageHandler mit dem gegebenen Qualifier einfügt. Der MessageHandler ist definiert als Bean mit demselben Qualifikationsmerkmal und Verweis auf die Klasse, die injiziert werden soll. Diese Bean wird in einer XML-Datei definiert, die wiederum über beanRefContext.xml geladen wird.

Also, was brauche ich mehr?

Vielleicht ein paar Worte zu meiner Bereitstellung. Theres eine Ear-Datei enthält a) meine MDBs als separate JAR-Modul und b) eine War-Datei mit meiner Web-Anwendung und c) die Lib-Ordner und Meta-Inf enthält alle verwendeten Bibliotheken (einschließlich der MessageHandler-Klasse injiziert werden) .

Wenn Sie weitere Informationen benötigen, fragen Sie bitte danach. Danke für jede Hilfe.

+0

vielleicht das Problem ist, was Frühling API-Dokumentationen sagen: „Hinweis: Wenn Sie mehr als eine Application Definition geteilt verfügbar in Ihrem EJB class loader, benötigen Sie " Die Anwendung (ein Ohr-Projekt) besitzt einige jar-Module (auch mit Feder-und Autowinding), ein ejb-Modul (enthält die Message Driven Beans) und ein Kriegsmodul (mit der Web-App). Da aber die Dokumentation "EJB3-konforme Interceptor-Klasse" sagt, sollten auch ejb-Module unterstützt werden. – Kaspatoo

+0

Ich habe keine wirkliche Quelle, aber ich denke, dass das Kriegsprojekt auf alle Bibliotheken innerhalb des äußeren Ohrprojekts zugreifen und seinen eigenen Anwendungskontext initialisieren kann. Aber das EJB-Modul, das direkt unter dem Ohr-Modul platziert ist, kann nicht auf den Anwendungskontext zugreifen, der jetzt innerhalb des inneren Kriegsmoduls gehalten wird. Ich meine, der EJB kann nicht in den Krieg schauen. Diese klare Trennung muss im Laufe der Jahre neu sein, da mehrere Treffer bei Google sagen, dass es einfach war, den Kontext auch über ein Kriegsmodul zu teilen. Momentan kann ich den ejb nicht in das Kriegsmodul integrieren. – Kaspatoo

Antwort