Message Driven Beans with "Required" CMT and duplicate delivery of messages

Hi,
Let's pretend that an MDB is configured with CMT and the "Required" transaction attribute. Let's suppose that it has received a message and is busy processing it in a transaction that might take some time to complete.
Is a JEE container required to ensure that while a message is being handled by an MDB in a transaction that's neither completed nor rolled back, no dupes of the same message should be delivered to another instance of the same MDB?

user572625 wrote:
Hi,
Let's pretend that an MDB is configured with CMT and the "Required" transaction attribute. Let's suppose that it has received a message and is busy processing it in a transaction that might take some time to complete.
Is a JEE container required to ensure that while a message is being handled by an MDB in a transaction that's neither completed nor rolled back, no dupes of the same message should be delivered to another instance of the same MDB?First, define "dupe".
Note that the main reason to use JEE technology over simpler frameworks is robustness, so if I understand your slightly vague question correctly, you can make the safe assumption that the answer is yes.

Similar Messages

SONIC MQ - Message Driven Bean with CMT

Hi guys,
I am having hard time with MDB having container managed transaction with TX attribute required. I am using RAD 6.0.1 and the JMS provider is Sonic MQ.I have defined XAConnectionFactory on Sonic side. The MDB runs without any error, but when I shut down the app server the message appears back in the queue. When I use transaction attribute as NOT SUPPORTED everything runs as normal.
Am I missing something on the configuration here?
I am seeing the XA implementation classes in the sonic jar file, but do I need their resource adaptor from sonic?
Thanks
Matt

The current version of the white-paper that Raffi
          refers to covers through 7.0. For 8.1 see also
          http://edocs.bea.com/wls/docs81/ConsoleHelp/jms_config.html#accessing_foreign_providers
          and
          http://edocs.bea.com/wls/docs81/jms/j2ee_components.html
          these features can often make integration easier.
          Tom
          Raffi wrote:
          > Doug,
          >
          > You can find very detailed information on this topic at the link below. All
          > you need to do is specify the destination-jndi-name, initial-context-factory,
          > provider-url, and connection-factory-jndi-name in weblogic-ejb-jar.xml for the
          > non-BEA JMS provider for that specific MDB.
          >
          > ftp://edownload:[email protected]/pub/downloads/jmsproviders.pdf
          >
          > Hope that helps!
          >
          > Raffi
          >
          > Doug Chew <[email protected]> wrote:
          >
          >>Can someone give me an example on how to setup a message driven bean
          >>with a foreign JMS provider using the foreign JMS provider's implementation
          >>of a connection factory. i.e. binding the foreign JMS provider's connection
          >>factory to the JNDI tree.
          >>
          >>Thanks
          >
          >

Message Driven Beans: how to receive and send in a single session?

Hello
How to receive and send JMS messages in a message driven bean using a single session?
Thanks.

Are you referring to writing code within the onMessage method itself to receive JMS messages?
If so, that is not a pattern that is recommended, especially not in the case of a blocking JMS
receieve. If you must write an explicit JMS receive within an EJB component it's best to use
a "check the queue" approach where you give a very small timeout for the receive. That way
if the message is there it will be returned but if not the call will not block.
You'll also need to take the transactional settings of the onMessage method into account.
If your are sending a message and then waiting for a response, those two actions can
not be done within the same global transaction. For that, you'll need to either use
BMT and perform each in its own transaction or just not use global transactions at all,
in which case each send and receive operation will be atomic.
--ken

Message Driven Bean with Java Message Queue down

I have the following problem deploying my application.
It uses JMS and a remote openMQ for communication between servers. The problem is that the connection is not fully reliable so it can be up or down. For reconnecting I set the jms reconnect glassfish property so it reconnects if at some moment the connection gets lost. The problem arises when i try to deploy the application and there is no connection. It looks like it keeps retrying the connection but the application does not finish deployment until connection is available.
Is it possible to configure it in any way that the deployment continues even if there is no connection and keeps retrying until there is connection available?
Thanks a lot.
Approach 1
I'm trying to run the MDB initialization in a different thread. I tried both
I'm trying to assign a different thread to the MDB by two ways changing sun-ejb.jar.xml
        <bean-pool>
            <steady-pool-size>1</steady-pool-size>
            <resize-quantity>1</resize-quantity>
            <max-pool-size>1</max-pool-size>
            <pool-idle-timeout-in-seconds>60</pool-idle-timeout-in-seconds>
        </bean-pool>and also with
        <use-thread-pool-id>a-new-thread-pool</use-thread-pool-id>But I had no luck. Looks like it's waiting for this thread to end since it looks like it's getting the new thread but it waits for that thread to end to finish starting application so, in my case, application doesn't get deployed correctly..
Approach 2
I tried to run jms service in a different thread also...
asadmin create-resource-adapter-config --threadpools a-new-thread-pool jmsraNo luck

You could try the JMSJCA resource adapter ( [https://jmsjca.dev.java.net/|https://jmsjca.dev.java.net/] ) ; this is expressly designed to allow a MDB to be deployed even though the MQ broker is not available. It will then try to establish the connection in a background thread.
Nigel

Message-driven bean "loses" MDB icon and status

Using JDev v11.1.1.5.0, when I create a MDB in my project using the wizard, it initially is displayed with the MDB icon next to it (a little envelope with a paperclip). However, about a second later, the icon changes to a normal 'Java' icon (coffee cup). I've also noticed that the MDB class does NOT appear in the Project Properties | EJB Module | Annotated EJB 3.0 Classes list box. The net result is that when the application is deployed, the MDB doesn't get registered to listen, so it never receives JMS messages.
I tried creating a new application from scratch, and created the exact same MDB. In this application, the icon 'sticks', and the class DOES show up in the "Annotated EJB 3.0 Classes" list box in the Project Properties dialog. (And, it will correctly register to receive JMS message on deployment.)
So, obviously something is different/wrong with my actual application that is preventing it from recognizing that the MDB class is an MDB. But, I don't know what. I've looked at all the settings in the Project Properties, looked at the actual project's .jpr file, etc., and can't see anything that would cause one application to not recognize MDBs.
Does anyone have any suggestions on how to figure out why my MDB classes aren't recognized as such in the one Application?
Here's the class I'm trying to use:
package com.acme;
import javax.ejb.MessageDriven;
import javax.jms.Message;
import javax.jms.MessageListener;
@MessageDriven(mappedName = "acme.DefaultQueue")
public class MessageEJB implements MessageListener {
public void onMessage(Message message) {
// ... code here ...
Thanks,
Karl

For those that might have this problem down the road, here's what I found... It seems that there was a corrupt "cache" file or something in the project. Specifically, I had to delete the files in the <app_name>\<project_name>\classes\.data\00000000 folder. Once I deleted those files (mostly .jdb files), and restarted JDeveloper, the correct icon displayed next to my MDB classes, AND they also showed up correctly in the Project Properties | EJB Console pane.
I'm not sure what these files are, but I assume they are cache files and get re-created automatically by JDeveloper when needed. I hope this helps someone else that has the same problem!

WLS Cluster with Message Driven Beans and MQSeries on more than one Host

          With the Examples of http://developer.bea.com/jmsproviders.jsp and http://developer.bea.com/jmsmdb.jsp
          a MDB can be
          configured to work with MQSeries with one WLS Server. This works only, if a Queuemanager
          is started at the same Host that runs the WLS Server too.
          And the QueueConnectionFactory (QCF) is configured to TRANSPORT(BIND).
          In my configuration should be two WLS Servers and one JMS Queue (MQS) with the
          Queuemanager.
          A Message Driven Bean is deployed on both WLS Servers wich should get the Messages
          of this Queue.
          If one of the two WLS Servers fails the other WLS Server with the corresponding
          MDB should get the Messages of the
          MQSeries Queue.
          If the QCF is configured to TRANSPORT(Client) the Message Driven Bean can't start
          and the following Exception is thrown:
          <Jul 18, 2001 3:52:49 PM CEST> <Error> <J2EE> <Error deploying EJB Component :
          mdb_deployed
          weblogic.ejb20.EJBDeploymentException: Error deploying Message-Driven EJB:; nested
          exception is:
          javax.jms.JMSException: MQJMS2005: failed to create MQQueueManager for
          'btsun1a:TEST'
          javax.jms.JMSException: MQJMS2005: failed to create MQQueueManager for 'btsun1a:TEST'
          at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:434)
          I'm wondering, because their is a MQQueueManager on btsun1a; all Servers throws
          the same Exception when the MDB is deployed.
          The configuration of JMSadmin on both Hosts is the following:
          dis qcf(myQCF2)
          HOSTNAME(btsun1a)
          CCSID(819)
          TRANSPORT(CLIENT)
          PORT(1414)
          TEMPMODEL(SYSTEM.DEFAULT.MODEL.QUEUE)
          QMANAGER(TEST)
          CHANNEL(JAVA.CHANNEL)
          VERSION(1)
          dis q(myQueue)
          CCSID(819)
          PERSISTENCE(APP)
          TARGCLIENT(JMS)
          QUEUE(MYQUEUE)
          EXPIRY(APP)
          QMANAGER(TEST)
          ENCODING(NATIVE)
          VERSION(1)
          PRIORITY(APP)
          I think only TRANSPORT(CLIENT) can be used when i don't wan't to install a Queue
          and a QueueManager on each WLS Server.
          Does anybody know a problem of WLS 6.0 SP2 to cope with TRANSPORT(CLIENT)?


          With the Examples of http://developer.bea.com/jmsproviders.jsp and http://developer.bea.com/jmsmdb.jsp
          a MDB can be
          configured to work with MQSeries with one WLS Server. This works only, if a Queuemanager
          is started at the same Host that runs the WLS Server too.
          And the QueueConnectionFactory (QCF) is configured to TRANSPORT(BIND).
          In my configuration should be two WLS Servers and one JMS Queue (MQS) with the
          Queuemanager.
          A Message Driven Bean is deployed on both WLS Servers wich should get the Messages
          of this Queue.
          If one of the two WLS Servers fails the other WLS Server with the corresponding
          MDB should get the Messages of the
          MQSeries Queue.
          If the QCF is configured to TRANSPORT(Client) the Message Driven Bean can't start
          and the following Exception is thrown:
          <Jul 18, 2001 3:52:49 PM CEST> <Error> <J2EE> <Error deploying EJB Component :
          mdb_deployed
          weblogic.ejb20.EJBDeploymentException: Error deploying Message-Driven EJB:; nested
          exception is:
          javax.jms.JMSException: MQJMS2005: failed to create MQQueueManager for
          'btsun1a:TEST'
          javax.jms.JMSException: MQJMS2005: failed to create MQQueueManager for 'btsun1a:TEST'
          at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:434)
          I'm wondering, because their is a MQQueueManager on btsun1a; all Servers throws
          the same Exception when the MDB is deployed.
          The configuration of JMSadmin on both Hosts is the following:
          dis qcf(myQCF2)
          HOSTNAME(btsun1a)
          CCSID(819)
          TRANSPORT(CLIENT)
          PORT(1414)
          TEMPMODEL(SYSTEM.DEFAULT.MODEL.QUEUE)
          QMANAGER(TEST)
          CHANNEL(JAVA.CHANNEL)
          VERSION(1)
          dis q(myQueue)
          CCSID(819)
          PERSISTENCE(APP)
          TARGCLIENT(JMS)
          QUEUE(MYQUEUE)
          EXPIRY(APP)
          QMANAGER(TEST)
          ENCODING(NATIVE)
          VERSION(1)
          PRIORITY(APP)
          I think only TRANSPORT(CLIENT) can be used when i don't wan't to install a Queue
          and a QueueManager on each WLS Server.
          Does anybody know a problem of WLS 6.0 SP2 to cope with TRANSPORT(CLIENT)?

Example for message-style with Message Driven Bean

hi,
Can i have some examples of webservices message-style with
MDB?....
thanks

The current version of the white-paper that Raffi
          refers to covers through 7.0. For 8.1 see also
          http://edocs.bea.com/wls/docs81/ConsoleHelp/jms_config.html#accessing_foreign_providers
          and
          http://edocs.bea.com/wls/docs81/jms/j2ee_components.html
          these features can often make integration easier.
          Tom
          Raffi wrote:
          > Doug,
          >
          > You can find very detailed information on this topic at the link below. All
          > you need to do is specify the destination-jndi-name, initial-context-factory,
          > provider-url, and connection-factory-jndi-name in weblogic-ejb-jar.xml for the
          > non-BEA JMS provider for that specific MDB.
          >
          > ftp://edownload:[email protected]/pub/downloads/jmsproviders.pdf
          >
          > Hope that helps!
          >
          > Raffi
          >
          > Doug Chew <[email protected]> wrote:
          >
          >>Can someone give me an example on how to setup a message driven bean
          >>with a foreign JMS provider using the foreign JMS provider's implementation
          >>of a connection factory. i.e. binding the foreign JMS provider's connection
          >>factory to the JNDI tree.
          >>
          >>Thanks
          >
          >

Help : Message Driven bean seeing the same message multiple times.

( We are using weblogic 8.1 on Solaris )
We have a bunch of message driven beans with the transaction type as 'Container' and the acknowledge-mode mode as auto-acknowledge. They are consuming messages from a weblogic Queue ( javax.jms.Queue ). The MBD container is also weblogic 8.1.
We have 7 instances of the bean consuming messages.
Most of the messages are picked up and processed only once as expected.
But randomly we are seeing that sometimes the same message is delivered again ( Message.getJmsRedelivered = true ) eventhough it was once picked up and processed successfully once.
We are completely lost and our production machine is in big trouble as a result of this.
( Is it possible that weblogic uses unreliable UDP for acknowledging messages. If yes where do we change this setting )
Any help will be greatly appreciated
Thanks
--sony
================ejb-jar.xml BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
<ejb-jar>
<enterprise-beans>
<message-driven>
<description>DslUpdtDdpostPrcsrMDB</description>
<ejb-name>DslUpdtDdpostPrcsrMDB</ejb-name>
<ejb-class>
com.bellsouth.snt.idm.ejb.wfac.DslUpdtDdpostPrcsrMDB
</ejb-class>
<transaction-type>Container</transaction-type>
<message-selector>
<![CDATA[ idm_state = 'dsl_updt_dd_post' ]]>
</message-selector>
<acknowledge-mode>auto-acknowledge</acknowledge-mode>
<message-driven-destination>
<destination-type>javax.jms.Queue</destination-type>
</message-driven-destination>
<env-entry>
          <env-entry-name>MDB_NAME</env-entry-name>
          <env-entry-type>java.lang.String</env-entry-type>
          <env-entry-value>dsl_updt_dd_post</env-entry-value>
</env-entry>

<resource-ref>
<res-ref-name>jms/QueueConnectionFactory</res-ref-name>
<res-type>javax.jms.QueueConnectionFactory</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
</message-driven>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>DslUpdtDdpostPrcsrMDB</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
================ejb-jar.xml END
================weblogic-ejb-jar.xml BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 8.1.0 EJB//EN' 'http://www.bea.com/servers/wls810/dtd/weblogic-ejb-jar.dtd'>
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>DslUpdtDdpostPrcsrMDB</ejb-name>
<message-driven-descriptor>
<pool>
<max-beans-in-free-pool>10</max-beans-in-free-pool>
<initial-beans-in-free-pool>0</initial-beans-in-free-pool>
</pool>
<destination-jndi-name>
idm.jms.clip.WfacClipResponseQueue
</destination-jndi-name>
<connection-factory-jndi-name>
idm.jms.IdmXaJmsQueueConnectionFactory
</connection-factory-jndi-name>
</message-driven-descriptor>
<transaction-descriptor>
<trans-timeout-seconds>
300
</trans-timeout-seconds>
</transaction-descriptor>
<reference-descriptor>
<resource-description>
<res-ref-name>jms/QueueConnectionFactory</res-ref-name>
<jndi-name>idm.jms.IdmXaJmsQueueConnectionFactory</jndi-name>
</resource-description>
</reference-descriptor>
<jndi-name>jms.DslUpdtDdpostPrcsrMDB</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
================weblogic-ejb-jar.xml END

The transaction attribute for the MDB is set to 'Required'. Is it possible
that your application logic may process the message successfully even in
case of a transaction roll back? If the transaction rolls back, the message
will be re-delivered.
There is some docs on exactly-once processing which may help
http://e-docs.bea.com/wls/docs81/ejb/message_beans.html#1147208
--Sathish
<Sony Antony> wrote in message news:[email protected]...
( We are using weblogic 8.1 on Solaris )
We have a bunch of message driven beans with the transaction type as
'Container' and the acknowledge-mode mode as auto-acknowledge. They are
consuming messages from a weblogic Queue ( javax.jms.Queue ). The MBD
container is also weblogic 8.1.
We have 7 instances of the bean consuming messages.
Most of the messages are picked up and processed only once as expected.
But randomly we are seeing that sometimes the same message is delivered
again ( Message.getJmsRedelivered = true ) eventhough it was once picked
up and processed successfully once.
We are completely lost and our production machine is in big trouble as a
result of this.
( Is it possible that weblogic uses unreliable UDP for acknowledging
messages. If yes where do we change this setting )
Any help will be greatly appreciated
Thanks
--sony
================ejb-jar.xml BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
<ejb-jar>
<enterprise-beans>
<message-driven>
<description>DslUpdtDdpostPrcsrMDB</description>
<ejb-name>DslUpdtDdpostPrcsrMDB</ejb-name>
<ejb-class>
com.bellsouth.snt.idm.ejb.wfac.DslUpdtDdpostPrcsrMDB
</ejb-class>
<transaction-type>Container</transaction-type>
<message-selector>
<![CDATA[ idm_state = 'dsl_updt_dd_post' ]]>
</message-selector>
<acknowledge-mode>auto-acknowledge</acknowledge-mode>
<message-driven-destination>
<destination-type>javax.jms.Queue</destination-type>
</message-driven-destination>
<env-entry>
<env-entry-name>MDB_NAME</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>dsl_updt_dd_post</env-entry-value>
</env-entry>

<resource-ref>
<res-ref-name>jms/QueueConnectionFactory</res-ref-name>
<res-type>javax.jms.QueueConnectionFactory</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
</message-driven>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>DslUpdtDdpostPrcsrMDB</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
================ejb-jar.xml END
================weblogic-ejb-jar.xml BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic
8.1.0 EJB//EN'
'http://www.bea.com/servers/wls810/dtd/weblogic-ejb-jar.dtd'>
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>DslUpdtDdpostPrcsrMDB</ejb-name>
<message-driven-descriptor>
<pool>
<max-beans-in-free-pool>10</max-beans-in-free-pool>
<initial-beans-in-free-pool>0</initial-beans-in-free-pool>
</pool>
<destination-jndi-name>
idm.jms.clip.WfacClipResponseQueue
</destination-jndi-name>
<connection-factory-jndi-name>
idm.jms.IdmXaJmsQueueConnectionFactory
</connection-factory-jndi-name>
</message-driven-descriptor>
<transaction-descriptor>
<trans-timeout-seconds>
300
</trans-timeout-seconds>
</transaction-descriptor>
<reference-descriptor>
<resource-description>
<res-ref-name>jms/QueueConnectionFactory</res-ref-name>
<jndi-name>idm.jms.IdmXaJmsQueueConnectionFactory</jndi-name>
</resource-description>
</reference-descriptor>
<jndi-name>jms.DslUpdtDdpostPrcsrMDB</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
================weblogic-ejb-jar.xml END

Can you set isolation levels of message-driven bean transactions?

The problem: I have 3 different message-driven beans which each get a different type of message, except for a field that is common to all. That field is used as the primary key of an entity object. The message-driven beans configured to use a container managed transaction. Each message-driven bean, in processing the message, first does a lookup by primary key to see if the object associated with the key exists, and if it does not, it requests the entity's home object to create it. After that, they do further processing. The problem is that sometimes all the beans simultaneously get a message, resulting in each bean checking for the entity object at about the same time, and if they fail to find it (because none of them has created it yet), each creates an object, all with the same primary key. This is not caught until the beans start to complete their onMessage method, which I believe results in the container committing the transaction. One of the transactions will be committed successfully, while the other two will fail, get rolled back, and then be retried with the same message. The second time through, the other beans will find the entity object (since it has been created and committed) and they will complete correctly. In the end, they right thing occurs, except that there is a troubling exception or 2 in the log telling about the constraint violation (with the primary key) and the rollback. If it was just me, that would be fine, but our customer does not like to see exceptions in the log; that indicates to him that something is wrong.
So, I am looking for someway to make sure that the actions of the message-driven beans are serialized. One suggestion from a colleague was to set the isolation level of the transactions being used by the container in processing the message-driven beans' onMessage method. However, the documentation does not mention any way to do this for a message-driven bean. Suggestions?
Is the use of a UserTransaction a better way to do this? If I acquire a UserTransaction within the onMessage method of a message-driven bean, can I set its isolation level? How would this work? When I get a UserTransaction, does each client get a different transaction, or do they all get the same one?

(1) The WebLogic JMS "unit-of-order" feature is a heavily adopted feature that was specifically designed to handle similar use cases - see the JMS developer guide for extensive documentation. In your use case, if "key" is used to define UOO, then there's no limit on the number of keys that can be processed concurrently, but messages for any particular key will be processed single-threaded in the order in which they were first submitted.
Note that if you're using distributed destinations, the UOO feature is still fully supported - but the developer and/or administrator needs to decide whether to configure the destination to use "hash" or "path service" based routing (the JMS UOO edoc outlines the trade-offs).
(2) Another alternative is to use a single MDB with max-beans-free-pool that processes all three types (as the other poster suggested). I think this assumes all MDBs run on the same JVM.
(3) Another alternative is to use multiple queues, with a single MDB on each Q. Where some sort of hash algorithm is used to determine which Q is for the key. This approach is a "hand-coded" variant of the approach in (1) with "hash" based routing enabled...
(4) If all MDBs actually do run in the same JVM, a third alternative is to use code the application to use a common lock to protect each key, eg, something like:
// assume MyLock is simply a class with a "reference counter"
// assume some global "staticHM" hash map that is all MDBs can access
onMessage() {
MyLock lock = null;
key= msg.getKey();
synchronized(staticHM) {
lock = staticHM.get();
if (lock = null) {
lock = new lock();
staticHM.put(key, new lock());
lock.incRefCount();
try {
synchronized(lock) {
// only one onMessage will be able to lock a particular key at a time
do your work;
} finally {
synchronized(staticHT) {
if (lock.defRefCount() == 0) staticHM.remove(lock);
if (lock = null) staticHM.put(key);
If multiple threads get a message with the same key, then only one thread at a time will work on the key.
Hope this helps,
Tom

Problem deploying message driven bean using Log4j

Hello all.
Using JDeveloper 11.1.1.0.2, I'm having a problem with a message driven bean I've created and associated with a JMS queue.
I've created an EJB Module project in my application (in which some other projects exist), and created the bean. A simple test of the bean, sending a message through the jms queue and printing it on system.out in the mdb onMessage() worked just fine.
However, when I add apache commons logging to my mdb, things start to go wrong. Running the project on the integrated weblogic 10.3 server just fails during deployment, due to a NoClassDefFoundError on org/apache/log4j/Logger.
In project properties -> libraries and classpath, I've added a log4j library (Log4j-1.2.14.jar) next to Commons Logging 1.0.4 but it doesn't seem to matter anything.
The code of my message bean:
@MessageDriven(mappedName = "weblogic.wsee.DefaultQueue")
public class MyMessageBean implements MessageListener {
    // logger
    private static Log sLog = LogFactory.getLog(MyMessageBean.class);
    public void ejbCreate() {
    public void ejbRemove() {
    public void onMessage(Message message) {
        MapMessage mapmsg = null;
        try {
            if (message instanceof MapMessage) {
                mapmsg = (MapMessage)message;
                boolean msgRedelivered = mapmsg.getJMSRedelivered();
                String msgId = mapmsg.getJMSMessageID();
                if (!msgRedelivered) {
                    sLog.debug("****** Successfully received message " + msgId);
                } else {
                    sLog.debug("****** Successfully received redelivered message " + msgId);
                // Haal de inhoud op:
                int testInt = mapmsg.getInt("TestInt");
                sLog.debug("TestInt:" + testInt);
            } else {
                sLog.debug("Message of wrong type: " +
                                   message.getClass().getName());
        } catch (Exception e) {
            sLog.error("Fout in verwerken",e);
}Does anybody have any clue as to what I might be doing wrong or missing out here?
The complete stacktrace:
5-aug-2009 12:54:44 oracle.adf.share.config.ADFConfigFactory cleanUpApplicationState
INFO: Cleaning up application state
java.lang.ExceptionInInitializerError
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Class.java:247)
     at weblogic.ejb.container.dd.xml.EjbAnnotationProcessor.processWLSAnnotations(EjbAnnotationProcessor.java:1705)
     at weblogic.ejb.container.dd.xml.EjbDescriptorReaderImpl.processWLSAnnotations(EjbDescriptorReaderImpl.java:346)
     at weblogic.ejb.container.dd.xml.EjbDescriptorReaderImpl.createReadOnlyDescriptorFromJarFile(EjbDescriptorReaderImpl.java:192)
     at weblogic.ejb.spi.EjbDescriptorFactory.createReadOnlyDescriptorFromJarFile(EjbDescriptorFactory.java:93)
     at weblogic.ejb.container.deployer.EJBModule.loadEJBDescriptor(EJBModule.java:1198)
     at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:380)
     at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93)
     at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:387)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
     at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:58)
     at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:42)
     at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:615)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
     at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:191)
     at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:16)
     at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:155)
     at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)
     at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:197)
     at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:89)
     at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:217)
     at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:723)
     at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1190)
     at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:248)
     at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:159)
     at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:157)
     at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12)
     at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45)
     at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@51b296 for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Logger) (Caused by org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@51b296 for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Logger))
     at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
     at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
     at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
     at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
     at nl.justid.dolores.mdb.MyMessageBean.<clinit>(MyMessageBean.java:19)
     ... 32 more
Caused by: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@51b296 for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Logger)
     at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
     at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
     ... 36 more
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
     at java.lang.Class.getDeclaredConstructors0(Native Method)
     at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
     at java.lang.Class.getConstructor0(Class.java:2699)
     at java.lang.Class.getConstructor(Class.java:1657)
     at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
     ... 37 more
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger
     at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
     at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
     ... 42 more
<5-aug-2009 12:54:44 uur CEST> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with ID '1249469684085' for task '14'. Error is: 'weblogic.application.ModuleException: Exception preparing module: EJBModule(Dolores-MessageBeans-ejb)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
null.'
weblogic.application.ModuleException: Exception preparing module: EJBModule(Dolores-MessageBeans-ejb)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
null.
     at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:452)
     at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93)
     at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:387)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
     at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:58)
     Truncated. see log file for complete stacktrace
java.lang.ClassNotFoundException: org.apache.log4j.Logger
     at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
     at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
     Truncated. see log file for complete stacktrace
>
5-aug-2009 12:54:44 oracle.adf.share.config.ADFConfigFactory cleanUpApplicationState
INFO: Cleaning up application state
<5-aug-2009 12:54:44 uur CEST> <Warning> <Deployer> <BEA-149004> <Failures were detected while initiating deploy task for application 'Dolores'.>
<5-aug-2009 12:54:44 uur CEST> <Warning> <Deployer> <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException: Exception preparing module: EJBModule(Dolores-MessageBeans-ejb)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
null.
     at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:452)
     at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93)
     at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:387)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
     at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:58)
     Truncated. see log file for complete stacktrace
java.lang.ClassNotFoundException: org.apache.log4j.Logger
     at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
     at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
     Truncated. see log file for complete stacktrace
>
[Deployer:149034]An exception occurred for task [Deployer:149026]deploy application Dolores on DefaultServer.: Exception preparing module: EJBModule(Dolores-MessageBeans-ejb)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
null..
weblogic.application.ModuleException: Exception preparing module: EJBModule(Dolores-MessageBeans-ejb)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
null.
#### Deployment incomplete. ####    Aug 5, 2009 12:54:44 PM
oracle.jdeveloper.deploy.DeployException
     at oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer.doDeploymentAction(Jsr88RemoteDeployer.java:247)
     at oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer.deployImpl(Jsr88RemoteDeployer.java:157)
     at oracle.jdeveloper.deploy.common.AbstractDeployer.deploy(AbstractDeployer.java:94)
     at oracle.jdevimpl.deploy.fwk.WrappedDeployer.deployImpl(WrappedDeployer.java:39)
     at oracle.jdeveloper.deploy.common.AbstractDeployer.deploy(AbstractDeployer.java:94)
     at oracle.jdeveloper.deploy.common.BatchDeployer.deployImpl(BatchDeployer.java:82)
     at oracle.jdeveloper.deploy.common.AbstractDeployer.deploy(AbstractDeployer.java:94)
     at oracle.jdevimpl.deploy.fwk.WrappedDeployer.deployImpl(WrappedDeployer.java:39)
     at oracle.jdeveloper.deploy.common.AbstractDeployer.deploy(AbstractDeployer.java:94)
     at oracle.jdevimpl.deploy.fwk.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:436)
     at oracle.jdeveloper.deploy.DeploymentManager.deploy(DeploymentManager.java:209)
     at oracle.jdevimpl.runner.adrs.AdrsStarter$5$1.run(AdrsStarter.java:1365)
Caused by: oracle.jdeveloper.deploy.DeployException
     at oracle.jdevimpl.deploy.common.Jsr88DeploymentHelper.deployApplication(Jsr88DeploymentHelper.java:413)
     at oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer.doDeploymentAction(Jsr88RemoteDeployer.java:238)
     ... 11 more
Caused by: oracle.jdeveloper.deploy.DeployException: Deployment Failed
     at oracle.jdevimpl.deploy.common.Jsr88DeploymentHelper.deployApplication(Jsr88DeploymentHelper.java:395)
     ... 12 more
#### Cannot run application Dolores due to error deploying to DefaultServer.
[Application Dolores stopped and undeployed from Server Instance DefaultServer]Thanks in advance!
Greetings,
Eelse
Edited by: Eelse on Aug 5, 2009 1:57 PM
Edited by: Eelse on Aug 5, 2009 5:39 PM

Creating a new deployment profile (EAR) and including the original deployment (JAR) and the needed libraries (in a lib-directory) solved the problem.

Message-driven bean questions

Hello,
i'm an Italian student trying to develop java applications in NetBeans IDE 6.1 with GlassFish V2, using Java EE 5; since I only recently approached java web programming, I have encountered some problems in using enterprise beans, especially message-driven ones: to get in touch with the stuff, I have created an enterprise application project in NetBeans with a plain message-driven bean and a servlet who sends a message to this bean, following an online netbeans tutorial.
I'm using annotations to refer the resource in the servlet (the jms name I assigned the bean is "TestBean"):
@Resource(mappedName="jms/TestBeanFactory")
private ConnectionFactory connectionFactory;
@Resource(mappedName="jms/TestBean")
private Queue queue;I send the message by creating a connection, producing the message with a MessageProducer object, and sending it:
Connection connection = connectionFactory.createConnection();
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageProducer messageProducer = session.createProducer(queue);
TextMessage message = session.createTextMessage("This is a message.");
messageProducer.send(message);
messageProducer.close();
connection.close();In the message-driven bean, I have my onMessage() method catching the message and writing to the system.out his text content:
public void onMessage(Message message)
        TextMessage msg = null;
        try
            if (message instanceof TextMessage)
                msg = (TextMessage) message;
                String x = msg.getText();
                System.out.println(x);
        catch (Exception e)
            e.printStackTrace();
            m_ctx.setRollbackOnly();
        catch (Throwable te)
            te.printStackTrace();
    }The message is sent and received, and the content printed. Ok, here are my questions:
1) in the output window of netbeans I see the output but also an exception: "DirectConsumer:Caught Exception delivering messagecom.sun.messaging.jmq.io.Packet cannot be cast to com.sun.messaging.jms.ra.DirectPacket". What does that mean?
2) I can't figure out how to make the bean answer this message to the servlet...and of course the servlet receive this response: in plain words, I would like to send back another message from the bean to the servlet, and process it. Can someone explain me how to do that?
Thanks?

1) in the output window of netbeans I see the output but also an exception: "DirectConsumer:Caught Exception delivering messagecom.sun.messaging.jmq.io.Packet cannot be cast to com.sun.messaging.jms.ra.DirectPacket". What does that mean?casting issue, but i don't know why.
2) I can't figure out how to make the bean answer this message to the servlet...and of course the servlet receive this response: in plain words, I would like to send back another message from the bean to the servlet, and process it. Can someone explain me how to do that?a message driven bean cannot sent a response back. MDB is asynchronous. if you need to send a response back, you
shouldn't be using an MDB. In that case, it sounds like you want a synchronous response. let a SLSB do it.
%

SAP WAS SS13 Message driven bean start up problem

Hello,
After we have upgraded our environment from SS9 to SS13 our app doesn't start anymore with the following exception (worked fine before):
com.sap.engine.services.deploy.exceptions.ServerDeploymentException: Exception in operation startApp with application
<skipped>
Caused by: java.lang.NoSuchMethodException: com.sap.engine.services.ejb.message.SrvSessionPool.<init>(com.sap.engine.services.ejb.util.pool.PoolUser, com.sap.engine.services.ejb.Environment, java.util.Properties)
ejb-jar.xml contains the reference to the class which couldn't be loaded:
<property>
<property-name>PoolClass</property-name>
<property-value>
   com.sap.engine.services.ejb.message.SrvSessionPool
</property-value>
</property>
Is there something we're missing? Please help! Thanks!
P.S. Full stack trace below:
Date : 09/06/2005
Time : 18:10:13:655
Category : /System/Audit
Message ID : 00C09F09C00700200000000300000B8000040021B1330F51
Severity : Error
Location : com.sap.engine.services.deploy
Source Name : com.sap.engine.services.deploy
Thread : SAPEngine_System_Thread[impl:5]_62
Message : Exception com.sap.engine.services.deploy.exceptions.ServerDeploymentException: Exception in operation startApp with application ourapp.com/App36.
     at com.sap.engine.services.deploy.server.application.ApplicationTransaction.rollbackPart(ApplicationTransaction.java:387)
     at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhasesOnOneServer(ApplicationTransaction.java:301)
     at com.sap.engine.services.deploy.server.application.ParallelAdapter.makeAllPhasesImpl(ParallelAdapter.java:301)
     at com.sap.engine.services.deploy.server.application.ParallelAdapter.run(ParallelAdapter.java:73)
     at com.sap.engine.frame.core.thread.Task.run(Task.java:60)
     at com.sap.engine.core.thread.impl5.SingleThread.execute(SingleThread.java:74)
     at com.sap.engine.core.thread.impl5.SingleThread.run(SingleThread.java:140)
Caused by: com.sap.engine.services.ejb.exceptions.deployment.EJBDeploymentException: Exception during the initialization of container boot class com.nrx.beans.job_handler.JobHandlerBean10ContainerFP.
     at com.sap.engine.services.ejb.EJBAdmin.prepareLoad(EJBAdmin.java:994)
     at com.sap.engine.services.ejb.EJBAdmin.prepareStart(EJBAdmin.java:2402)
     at com.sap.engine.services.deploy.server.application.StartTransaction.prepareCommon(StartTransaction.java:370)
     at com.sap.engine.services.deploy.server.application.StartTransaction.prepare(StartTransaction.java:318)
     at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhasesOnOneServer(ApplicationTransaction.java:299)
     ... 5 more
Caused by: com.sap.engine.services.ejb.ContainerInitializationException: Cannot initialize message system bridge com.sap.engine.services.ejb.message.JMSBridgeFP.
     at com.sap.engine.services.ejb.message.MessageContainer.load(MessageContainer.java:457)
     at com.sap.engine.services.ejb.message.MessageContainer.init(MessageContainer.java:146)
     at com.sap.engine.services.ejb.message.MessageContainerFP.init(MessageContainerFP.java:53)
     at com.sap.engine.services.ejb.EJBAdmin.prepareLoad(EJBAdmin.java:988)
     ... 9 more
Caused by: com.sap.engine.services.ejb.message.JMSBridgeException: Cannot initialize the message-driven bean container.
     at com.sap.engine.services.ejb.message.JMSBridge.registerListener(JMSBridge.java:113)
     at com.sap.engine.services.ejb.message.MessageContainer.load(MessageContainer.java:455)
     ... 12 more
Caused by: com.sap.engine.services.ejb.ContainerInitializationException: Cannot create a session pool for message-driven bean JobHandlerBean.
     at com.sap.engine.services.ejb.message.JMSBridge.initPool(JMSBridge.java:219)
     at com.sap.engine.services.ejb.message.JMSBridge.registerListener(JMSBridge.java:96)
     ... 13 more
Caused by: java.lang.NoSuchMethodException: com.sap.engine.services.ejb.message.SrvSessionPool.<init>(com.sap.engine.services.ejb.util.pool.PoolUser, com.sap.engine.services.ejb.Environment, java.util.Properties)
     at java.lang.Class.getConstructor0(Class.java:1937)
     at java.lang.Class.getConstructor(Class.java:1027)
     at com.sap.engine.services.ejb.message.JMSBridge.initPool(JMSBridge.java:205)
     ... 14 more

Hello,
After we have upgraded our environment from SS9 to SS13 our app doesn't start anymore with the following exception (worked fine before):
com.sap.engine.services.deploy.exceptions.ServerDeploymentException: Exception in operation startApp with application
<skipped>
Caused by: java.lang.NoSuchMethodException: com.sap.engine.services.ejb.message.SrvSessionPool.<init>(com.sap.engine.services.ejb.util.pool.PoolUser, com.sap.engine.services.ejb.Environment, java.util.Properties)
ejb-jar.xml contains the reference to the class which couldn't be loaded:
<property>
<property-name>PoolClass</property-name>
<property-value>
   com.sap.engine.services.ejb.message.SrvSessionPool
</property-value>
</property>
Is there something we're missing? Please help! Thanks!
P.S. Full stack trace below:
Date : 09/06/2005
Time : 18:10:13:655
Category : /System/Audit
Message ID : 00C09F09C00700200000000300000B8000040021B1330F51
Severity : Error
Location : com.sap.engine.services.deploy
Source Name : com.sap.engine.services.deploy
Thread : SAPEngine_System_Thread[impl:5]_62
Message : Exception com.sap.engine.services.deploy.exceptions.ServerDeploymentException: Exception in operation startApp with application ourapp.com/App36.
     at com.sap.engine.services.deploy.server.application.ApplicationTransaction.rollbackPart(ApplicationTransaction.java:387)
     at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhasesOnOneServer(ApplicationTransaction.java:301)
     at com.sap.engine.services.deploy.server.application.ParallelAdapter.makeAllPhasesImpl(ParallelAdapter.java:301)
     at com.sap.engine.services.deploy.server.application.ParallelAdapter.run(ParallelAdapter.java:73)
     at com.sap.engine.frame.core.thread.Task.run(Task.java:60)
     at com.sap.engine.core.thread.impl5.SingleThread.execute(SingleThread.java:74)
     at com.sap.engine.core.thread.impl5.SingleThread.run(SingleThread.java:140)
Caused by: com.sap.engine.services.ejb.exceptions.deployment.EJBDeploymentException: Exception during the initialization of container boot class com.nrx.beans.job_handler.JobHandlerBean10ContainerFP.
     at com.sap.engine.services.ejb.EJBAdmin.prepareLoad(EJBAdmin.java:994)
     at com.sap.engine.services.ejb.EJBAdmin.prepareStart(EJBAdmin.java:2402)
     at com.sap.engine.services.deploy.server.application.StartTransaction.prepareCommon(StartTransaction.java:370)
     at com.sap.engine.services.deploy.server.application.StartTransaction.prepare(StartTransaction.java:318)
     at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhasesOnOneServer(ApplicationTransaction.java:299)
     ... 5 more
Caused by: com.sap.engine.services.ejb.ContainerInitializationException: Cannot initialize message system bridge com.sap.engine.services.ejb.message.JMSBridgeFP.
     at com.sap.engine.services.ejb.message.MessageContainer.load(MessageContainer.java:457)
     at com.sap.engine.services.ejb.message.MessageContainer.init(MessageContainer.java:146)
     at com.sap.engine.services.ejb.message.MessageContainerFP.init(MessageContainerFP.java:53)
     at com.sap.engine.services.ejb.EJBAdmin.prepareLoad(EJBAdmin.java:988)
     ... 9 more
Caused by: com.sap.engine.services.ejb.message.JMSBridgeException: Cannot initialize the message-driven bean container.
     at com.sap.engine.services.ejb.message.JMSBridge.registerListener(JMSBridge.java:113)
     at com.sap.engine.services.ejb.message.MessageContainer.load(MessageContainer.java:455)
     ... 12 more
Caused by: com.sap.engine.services.ejb.ContainerInitializationException: Cannot create a session pool for message-driven bean JobHandlerBean.
     at com.sap.engine.services.ejb.message.JMSBridge.initPool(JMSBridge.java:219)
     at com.sap.engine.services.ejb.message.JMSBridge.registerListener(JMSBridge.java:96)
     ... 13 more
Caused by: java.lang.NoSuchMethodException: com.sap.engine.services.ejb.message.SrvSessionPool.<init>(com.sap.engine.services.ejb.util.pool.PoolUser, com.sap.engine.services.ejb.Environment, java.util.Properties)
     at java.lang.Class.getConstructor0(Class.java:1937)
     at java.lang.Class.getConstructor(Class.java:1027)
     at com.sap.engine.services.ejb.message.JMSBridge.initPool(JMSBridge.java:205)
     ... 14 more

Only one Message Driven Bean

hi
i have some heavy calculating beans and i want that only one EJB is calculating at one time. can i do this by using Message Driven Beans? is it possible that the server creates only one Message Driven Bean at one time and gets the next one out of the queue when the old one finished calculating?
thanks, jo

It is possible to set up that there should be only one mdb in the pool, but it's not quite what mdbs are intended for. Remember that this is an asynchronous message service, and you will not receive a reply after you put a message on the queue.

Cache Synchronization with JMS and a Message Driven Bean (MDB)

If I understand correctly, Toplink ueses the following configuration info to find the target to publish its session messages to a JMS server (having its URL as below) which provides the JNDI service that Toplink needs to look up the topic:
<cache-synchronization-manager>
<clustering-service> oracle.toplink.remote.jms.mdb.JMSPublishingOnlyClusteringService
</clustering-service>
<should-remove-connection-on-error>false</should-remove-connection-on-error>


<jms-topic-connection-factory-name> jms/TopLinkTopicConectionFactory
</jms-topic-connection-factory-name>
<jms-topic-name>jms/TopLinkCacheSynchTopic</jms-topic-name>


<naming-service-url>ormi://localhost:23791</naming-service-url>
<naming-service-initial-context-factory> com.evermind.server.rmi.RMIInitialContextFactory </naming-service-initial-context-factory></cache-synchronization-manager>
The MDB also uses the same JNDI service provided by the JMS server to listen to the topic which is named in the ejb-jar.xml file:
<enterprise-beans>
<message-driven>
<display-name>TopLink clustering MDB</display-name>
<ejb-name>TopLinkClusteringMDB</ejb-name>
<ejb-class>com.mycompany.mdb.ClusteringMDB</ejb-class>
<transaction-type>Container</transaction-type>
<message-driven-destination> <destination-type>javax.jms.Topic</destination-type>
</message-driven-destination>
<env-entry>
<description>TopLink session name</description>
<env-entry-name>tl_session_name_for_mdb</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>Employee_Session</env-entry-value>
</env-entry>
<resource-ref> <description>description</description>
<res-ref-name>jms/TopLinkTopicConectionFactory</res-ref-name>
<res-type>javax.jms.TopicConnectionFactory</res-type>
<res-auth>Application</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
<resource-env-ref>
<resource-env-ref-name> jms/TopLinkCacheSynchTopic</resource-env-ref-name>
<resource-env-ref-type>javax.jms.Topic</resource-env-ref-type> </resource-env-ref>
</message-driven></enterprise-beans>
To do this, the EJB container that hosts the above MDB needs to be configured to know where the JMS server is by using the above URL same as in the Toplink sessions.xml file.
I am not clear that who provides the JNDI service for the Toplink session name lookup used by the MDB:
// Obtain the Session name configured in the environment variable
String sessionName = (String) myEnv.lookup(TOPLINK_SESSION_NAME);
session = SessionManager.getManager().getSession(sessionName);
so that the MDB can find the currently running Toplink session and communicate with it.
Can anybody help answer my above question and correct my understandings?
Many thanks!

Although TopLink is running in the application serverâs VM, the only notable integration points with the server are for JTA and user-defined data sources. All of the work performed to get a session via SessionManager occurs solely within TopLink. When the call is made to retrieve a session, you arenât getting the âactiveâ session identified by âEmployee_Sessionâ that is registered with the application server, rather a new session is created using the definition that exists for âEmployee_Sessionâ in sessions.xml.
When the call âsession = SessionManager.getManager().getSession(âEmployee_Sessionâ)â is made, the SessionManager simply looks for sessions.xml at the root level of its deployed jars or classpath, then looks for the âEmployee_Sessionâ tag within sessions.xml. If a session exists in the file with that name then a TopLink session object is created and returned.
Note that setting an environment entry as mentioned above simply allows for the session name to be declared dynamically. The call to âmyEnv.lookup(âtl_session_name_for_mdbâ)â simply asks the beanâs environment for the <env-entry-value> that matches the <env-entry-name>. That string is then used in SessionManager (no different than a hard coded value would be) to identify the session in sessions.xml that is to be loaded.
I hope this makes sense.

B2B using JMS and Processing Messages with Message Driven Beans

We want to be able to use B2B to send messages to a JMS queue and then process messages from B2B using a Message Driven Bean. Is this supported.
We are using B2B 10.2.0.2 with Patchset 4.

Hello,
In 10.1.2.0.2 B2B , as part of the internal Delivery channel B2B can only send and receive messages from JMS queues.
Rgds,Ramesh

Message Driven Beans with "Required" CMT and duplicate delivery of messages

Similar Messages

Maybe you are looking for