I have nearly the same exact setup, except that:
1) I am still on WL 6.1;
2) I use a custom log4j appender which logs to a queue instead of a topic
I did have a little bit of issues getting the message-driven beans to work
(not just the logging consumer, but other processes also). WebLogic was a
little bit cluggy in its JMS setup (though I was hoping this all would have
changed in the new release).
However, I can confirm that this type of setup is working (beautifully) for
me.
Here is the pertinent stuff from my deployment descrioptor:
<enterprise-beans>
<message-driven>
...
<ejb-name>LoggingQueueConsumer</ejb-name>
...
<transaction-type>Container</transaction-type>
...
</message-driven>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>LoggingQueueConsumer</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>NotSupported</trans-attribute>
</container-transaction>
</assembly-descriptor>
***Notice that there is no
"<acknowledge-mode>Auto-acknowledge</acknowledge-mode>". This never seemed
to make any difference in our setup. I actually had to move the acknowleged
into the bean itself. And the actual place in which the acknowledement
happened seemed to matter greatly also (ain't weblogic grand?). Here is
onMessage() method:
public void onMessage( Message message )
{
// This is the method called by the container when a message is
// received on the queue to which this bean is set to listen.
ObjectMessage msg = null;
try
{
// First, make sure the message is of type ObjectMessage
// (i.e., message contains a serialized object.
if (message instanceof ObjectMessage)
{
Object ref = ((ObjectMessage)message).getObject();
// Next, make sure the message's serialized object is of
// type LogRequestMessage
if (ref instanceof LoggingEvent)
{
message.acknowledge();
processMessage( (LoggingEvent)ref );
}
else
{
log.info( "Unable to handle ObjectMessage with obect
type "
+ ref.getClass().getName() );
}
}
else
{
log.info( "Unable to handle Message of type " +
message.getClass().getName() );
}
}
catch ( JMSException jmse )
{
log.error( "Error retreiving incoming message", jmse );
mdc.setRollbackOnly();
}
catch ( Throwable e )
{
log.error( "Error retreiving incoming message", e );
mdc.setRollbackOnly();
}
}
Message.acknowledge() had to be the very first call as soon as I knew that I
was interested in this message (i.e., as soon as I knew it was of type
LoggingEvent).
Again, these may have been corrected in the new release, but the problems
you are facing sound awfully similiar to what I faced.
HTH
|-----Original Message-----
|From: Benary Klaus [mailto:[EMAIL PROTECTED]]
|Sent: Friday, September 06, 2002 8:16 AM
|To: '[EMAIL PROTECTED]'
|Subject: AW: JMSAppender in Container Managed Transactions
|
|
|Hi Steven, hi Ceki,
|
|There is a listener bean durably subscribed to the topic.
|The crucial part of the deployment descriptor is:
|
|<message-driven>
| <display-name></display-name>
| <ejb-name>ListenerBean</ejb-name>
| <ejb-class>com.jcoffee.base.sl.ListenerBean</ejb-class>
| <transaction-type>Container</transaction-type>
| <acknowledge-mode>Auto-acknowledge</acknowledge-mode>
| <message-driven-destination>
| <destination-type>javax.jms.Topic</destination-type>
| <subscription-durability>Durable</subscription-durability>
| </message-driven-destination>
| <resource-ref>
| <res-ref-name>jdbc/DS</res-ref-name>
| <res-type>javax.sql.DataSource</res-type>
| <res-auth>Container</res-auth>
| </resource-ref>
|</message-driven>
|
|But, I think that the consumer cannot be the reason for
|this behavior. The
|producer side
|would behave the same way even if there was no consumer
|subscribed at all.
|Besides: It is BEA 7.00 and WebLogic JMS according to JavaSoft JMS
|specification version 1.0.2.
|
|Klaus
|
|
|
|> -----Ursprüngliche Nachricht-----
|> Von: [EMAIL PROTECTED]@GEHE
|> Gesendet: Freitag, 6. September 2002 14:49
|> An: [EMAIL PROTECTED]
|> Betreff: RE: JMSAppender in Container Managed Transactions
|>
|> JMSAppender opens its session to the JMS server in
|"AUTO_ACKNOWLEDGE",
|> non-transacted mode. Basically, this means the message should be
|> "delivered" no matter what. So the JMSAppender is
|already set up to
|> operate
|> outside of currently running transactions.
|>
|> How are you processing the messages from the topic?
|MessageDrivenBean
|> MessageListener implementation? What is the set up of
|this consumption
|> piece?
|>
|>
|>
|> |-----Original Message-----
|> |From: Benary Klaus [mailto:[EMAIL PROTECTED]]
|> |Sent: Friday, September 06, 2002 7:21 AM
|> |To: '[EMAIL PROTECTED]'
|> |Subject: JMSAppender in Container Managed Transactions
|> |
|> |
|> |How can I decouple logging via JMSAppender from the
|> |contrainer transaction
|> |in a stateless session EJB?
|> |I want the JMSAppender to deliver logs even when I call
|> |SessionContext.setRollbackOnly(). As a default,
|> |JMS committs a message to the queue or topic only when the
|> |contrainer
|> |transaction committs. As a side
|> |effect, a log within a failing contrainer transaction
|> |shows up only in those
|> |appenders that do not use JMS.
|> |Am I missing something?
|> |Any help would be appreciated.
|> |
|> |Klaus
|> |
|> |
|> |--
|> |To unsubscribe, e-mail:
|> |<mailto:[EMAIL PROTECTED]>
|> |For additional commands, e-mail:
|> |<mailto:[EMAIL PROTECTED]>
|> |
|>
|> --
|> To unsubscribe, e-mail:
|> <mailto:[EMAIL PROTECTED]>
|> For additional commands, e-mail:
|> <mailto:[EMAIL PROTECTED]>
|>
|
|--
|To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
