0

I have an MDB which shall get its messageHandler implementation via autowiring. But at runtine this object is null. Even the breakpoint at the setter never has been reached. When having a breakpoint within the onMessage method of the BaseMDB (wich is extended by the following MDB) it is reached and I can see the messageHandler-object is null. I then am getting a nullpointer exception. Thats why I think that the autowiring does not work.

my MDB looks as follows:

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

As from whaat I have read the SpringBeanAutowiringInterceptor uses the default factory such that I need to have the beanRefContext.xml into class path. It looks as follows:

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

On startup the jboss console also shows me that all these xml files are loaded from beanRefContext.xml by saying:

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

So I think its correlty lying within classpath.

Within the container-context.xml theres amongst others the following entry:

<context:annotation-config/>

Within the container-services-context.xml theres amongst others the following line:

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

So my MDB has an intercepter which shall inject the messageHandler using the given qualifier. The MessageHandler is defined as bean with the same qualifier and refererring to the class which shall be injected. This bean is defined within an xml file which in turn is loaded via beanRefContext.xml.

So what do I need more?

Maybe some words to my deployment. Theres an ear-file containaing a) my MDBs as separate jar-module and b) a war-file containing my web application and c) the lib folder und meta-inf containing all libraries used (including the messageHandler class to be injected).

If you need any further information please just ask for it. Thanks for any help.

Kaspatoo
  • 1,223
  • 2
  • 11
  • 28
  • maybe the problem is what Spring API documentations says: "NOTE: If you have more than one shared ApplicationContext definition available in your EJB class loader, you need" The Application (an ear project) owns some jar-modules (also using spring and autowiring), a ejb-module (containing the message driven beans) and a war module (containing the webapp). But since documentation says "EJB3-compliant interceptor class" I think also ejb-modules should be supported. – Kaspatoo Feb 20 '17 at 12:44
  • I dont have a really source but I think that the war-project can access all libraries within the outer ear-project and initializes its own application context. But the EJB-Module, placed directly under the ear-module, cannot access the application context which is now held within the inner war-module. I mean the ejb cannot look into the war. This clear separation must be new over the years since multiple hits on google say that it was simply easy to share the context also over a war-module. Currently I fail to integrate the ejb into the war-module. – Kaspatoo Feb 20 '17 at 14:50

1 Answers1

0

I solved it by adding what is described for

<module name="test.module" annotations="true" />

found at: https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html/development_guide/class_loading_and_modules#add_an_explicit_module_dependency_to_a_deployment

Kaspatoo
  • 1,223
  • 2
  • 11
  • 28