У меня есть 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, который нужно вставить) ,
Если вам нужна дополнительная информация, просто спросите об этом. Спасибо за любую помощь.
может быть, проблема в том, что говорит Spring API Документация: «ПРИМЕЧАНИЕ: Если у вас есть более чем один общий определение ApplicationContext доступный в вашем загрузчике класса EJB, вам нужно « Приложение (проект уха) имеет некоторые jar-модули (также используя пружину и автоустановку), ejb-модуль (содержащий ведомые сообщения сообщения) и военный модуль (содержащий WebApp). Но так как документация говорит «класс перехватчика, совместимый с EJB3», я думаю, что также должны поддерживаться модули ejb. – Kaspatoo
У меня нет источника, но я думаю, что военный проект может получить доступ ко всем библиотекам внешнего проекта уха и инициализирует свой собственный контекст приложения. Но EJB-модуль, расположенный непосредственно под ушным модулем, не может получить доступ к контексту приложения, который теперь находится во внутреннем военном модуле. Я имею в виду, что ejb не может смотреть на войну. Это четкое разделение должно быть новым на протяжении многих лет, поскольку многие хиты в google говорят, что просто легко разделить контекст также над военным модулем. В настоящее время я не могу интегрировать ejb в военный модуль. – Kaspatoo