4

I want to deploy two instances of the same MDB to process messages from two different Queues under jboss7 with ActiveMQ. So hier is a part of my ejb-jar.xml:

<message-driven>
    <ejb-name>FirstInstanceOfMyMDB</ejb-name>
    <ejb-class>de.xx.xx.MyMDB</ejb-class>
    <activation-config>
        <activation-config-property>
            <activation-config-property-name>destination</activation-config-property-name>
            <activation-config-property-value>activemq/queue/queue_1</activation-config-property-value>
        </activation-config-property>
        <activation-config-property>
            <activation-config-property-name>destinationType</activation-config-property-name>
            <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
        </activation-config-property>
    </activation-config>
</message-driven>

<message-driven>
    <ejb-name>SecondInstanceOfMyMDB</ejb-name>
    <ejb-class>de.xx.xx.MyMDB</ejb-class>
    <activation-config>
        <activation-config-property>
            <activation-config-property-name>destination</activation-config-property-name>
            <activation-config-property-value>activemq/queue/queue_2</activation-config-property-value>
        </activation-config-property>
        <activation-config-property>
            <activation-config-property-name>destinationType</activation-config-property-name>
            <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
        </activation-config-property>
    </activation-config>
</message-driven>

With this configuration everything works well.

Now I want to add some instance-specific propeties to each instance: System = A for FirstInstanceOfMyMDB and System = B for SecondInstanceOfMyMDB.

I have already tried to use within the to get the System injected with @Resource annotation:

<message-driven>
        <ejb-name>FirstInstanceOfMyMDB</ejb-name>
        ...
<env-entry>
          <env-entry-name>System</env-entry-name>
          <env-entry-type>java.lang.String</env-entry-type>
          <env-entry-value>A</env-entry-value>
    </env-entry>
</message-driven>

<message-driven>
        <ejb-name>SecondInstanceOfMyMDB</ejb-name>
        ...
    <env-entry>
          <env-entry-name>System</env-entry-name>
          <env-entry-type>java.lang.String</env-entry-type>
          <env-entry-value>B</env-entry-value>
    </env-entry>
</message-driven>

But jboss seems to set System only once either to A or to B. Maybe because the same namespace is used to set the System.

So My Question: What is the best practice to set custom instance MDB (EJB) Proerties?

Using the approch suggested by user1181247:

@Resource(name="System")
private String System;

I can deploy my MDBs within a ejbmodule with ejb-jar.xml in METH-INF directory and thy work as desired. Tryint to deploy the same classes in a war file with the same ejb-jar.xml in WEB-INF folder I get following exception:

[0m[31m09:13:56,823 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."Server.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."Server.war".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "Server.war"
    at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
    ...
Caused by: java.lang.IllegalArgumentException: JBAS011053: Incompatible conflicting binding at java:comp/env/System source: org.jboss.as.ee.component.EnvEntryInjectionSource@1291e

If the env-entry-value is for both instances the same, deploying is done wihout exceptions!

Do I need another/additional configuration for a war file?

sam
  • 41
  • 3

2 Answers2

0

I have done pretty much the same injection with my MDBs which worked at one time with AS7 (I'm currently using EAP). The only possible difference I can see between what worked with mine and what you have is I had named my resources. So try this if you haven't already:

@Resource(name = "sysId")
protected String sysId;

More details...I have tested the following on EAP but worked for me on 7.1.1 previously.

My mdb:

public class TestMDB implements MessageListener {
    private static final Logger l = Logger.getLogger(TestMDB.class);

    @Resource(name="sysId")
    private String sysId;

    public void onMessage(Message arg0) {
        try {
            l.info("Received message " + sysId + " - " + ((TextMessage) arg0).getText());
        }
        catch (JMSException e) {
            l.error("Failed to get message", e);
        }
    }

}

from my ejb-jar

    <enterprise-beans>
        <message-driven>
            <ejb-name>receiver1</ejb-name>
            <ejb-class>com.xxxx.test.JMSTest.TestMDB</ejb-class>
            <activation-config>
                <activation-config-property>
                    <activation-config-property-name>destinationType</activation-config-property-name>
                    <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
                </activation-config-property>
                <activation-config-property>
                    <activation-config-property-name>destination</activation-config-property-name>
                    <activation-config-property-value>queue/xxxin</activation-config-property-value>
                </activation-config-property>
            </activation-config>
            <env-entry>
                <env-entry-name>sysId</env-entry-name>
                <env-entry-type>java.lang.String</env-entry-type>
                <env-entry-value>ID1</env-entry-value>
            </env-entry>
        </message-driven>
        <message-driven>
            <ejb-name>receiver2</ejb-name>
            <ejb-class>com.xxxx.test.JMSTest.TestMDB</ejb-class>
            <activation-config>
                <activation-config-property>
                    <activation-config-property-name>destinationType</activation-config-property-name>
                    <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
                </activation-config-property>
                <activation-config-property>
                    <activation-config-property-name>destination</activation-config-property-name>
                    <activation-config-property-value>queue/xxxinit</activation-config-property-value>
                </activation-config-property>
            </activation-config>
            <env-entry>
                <env-entry-name>sysId</env-entry-name>
                <env-entry-type>java.lang.String</env-entry-type>
                <env-entry-value>ID2</env-entry-value>
            </env-entry>
        </message-driven>
    </enterprise-beans>

Output:

11:43:20,082 INFO [com.xxxx.test.JMSTest.TestMDB] (Thread-2 (HornetQ-client-global-threads-319126730)) Received message ID1 - hi

11:43:25,088 INFO [com.xxxx.test.JMSTest.TestMDB] (Thread-2 (HornetQ-client-global-threads-319126730)) Received message ID2 - hi2

Marc
  • 78
  • 9
  • This approach works when MDB is deployed as jar (ejb-module) but not, if it is deployed in a war file. I completed my question. – sam Nov 29 '13 at 08:53
  • @sam Hmmmmm...have you tried this on anything more stable like 7.1.3? – Marc Nov 29 '13 at 16:52
0

I noticed this in the EJB spec:

16.2.1 Sharing of Environment Entries

For enterprise beans packaged in an ejb-jar, each enterprise bean defines its own set of environment entries. In this case, all instances of an enterprise bean share the same environment entries; the environment entries are not shared with other enterprise beans.

In a .war, there is only a single naming environment shared between all the components in the module. For enterprise beans packaged in a .war, all enterprise beans share this single naming environment. The enterprise beans share their environment entries with all other enterprise bean components and web components in the .war.

So it seems for some reason that the env-entry approach will work if you deploy an ejb jar but not a war. Maybe split your app up and move to an ear deployment if possible.

Marc
  • 78
  • 9