2017-02-17 23 views
0

У меня есть MDB, который должен получить его messageHandler через autowiring. Но в runtine этот объект имеет значение null. Даже точка останова в сеттере никогда не была достигнута. При наличии точки останова в методе onMessage BaseMDB (который расширяется следующим MDB) он достигнут, и я вижу, что messageHandler-объект имеет значение null. Я получаю исключение nullpointer. Вот почему я думаю, что автоустановка не работает.Весенняя инъекция в MessageDrivenBean не работает - null pointer - jboss eap 7

мой MDB выглядит следующим образом:

@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; 
    } 
} 

Как из whaat я прочитал SpringBeanAutowiringInterceptor использует фабрику по умолчанию таким образом, что мне нужно, чтобы иметь beanRefContext.xml в пути к классам. Он выглядит следующим образом:

<?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> 

при запуске системы JBoss консоль также показывает мне, что все эти XML-файлы загружаются из beanRefContext.xml, говоря:

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

Так что я думаю, что его correlty лежал в пути к классам.

В контейнерном context.xml Theres среди других следующую запись:

<context:annotation-config/> 

Внутри контейнера-сервисов context.xml Theres среди других следующие строки:

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

Так что мой В MDB есть интерсептер, который должен вводить messageHandler с использованием данного классификатора. MessageHandler определяется как бит с тем же квалификатором и ссылается на класс, который должен быть введен. Этот бит определен в XML-файле, который, в свою очередь, загружается через beanRefContext.xml.

Для чего мне нужно больше?

Возможно, некоторые слова для моего развертывания. Theres файл уха, содержащий a) мои MDB как отдельный jar-модуль и b) файл войны, содержащий мое веб-приложение, и c) папку lib und meta-inf, содержащую все используемые библиотеки (включая класс messageHandler, который нужно вставить) ,

Если вам нужна дополнительная информация, просто спросите об этом. Спасибо за любую помощь.

+0

может быть, проблема в том, что говорит Spring API Документация: «ПРИМЕЧАНИЕ: Если у вас есть более чем один общий определение ApplicationContext доступный в вашем загрузчике класса EJB, вам нужно « Приложение (проект уха) имеет некоторые jar-модули (также используя пружину и автоустановку), ejb-модуль (содержащий ведомые сообщения сообщения) и военный модуль (содержащий WebApp). Но так как документация говорит «класс перехватчика, совместимый с EJB3», я думаю, что также должны поддерживаться модули ejb. – Kaspatoo

+0

У меня нет источника, но я думаю, что военный проект может получить доступ ко всем библиотекам внешнего проекта уха и инициализирует свой собственный контекст приложения. Но EJB-модуль, расположенный непосредственно под ушным модулем, не может получить доступ к контексту приложения, который теперь находится во внутреннем военном модуле. Я имею в виду, что ejb не может смотреть на войну. Это четкое разделение должно быть новым на протяжении многих лет, поскольку многие хиты в google говорят, что просто легко разделить контекст также над военным модулем. В настоящее время я не могу интегрировать ejb в военный модуль. – Kaspatoo

ответ