I am sure that it works for me. ;0)
Yes, I have session beans which are marked to let WebLogic manage its
transactions as "Required". If something should go wrong in one of them, I
send a log message with the underlying exception, throw a custom exception,
and set the transaction for rollback only and that log message shows up in
the JMS queue and is processed by the MDB and is placed into the appropriate
log file.
I don't know what elese to tell you. I did have a lot of problems getting
this set up just right in WebLogic. In my case it was never a problem with
log4j or the JMSAppender, but more the WebLogic JMS implementation.
|-----Original Message-----
|From: Benary Klaus [mailto:[EMAIL PROTECTED]]
|Sent: Friday, September 06, 2002 9:24 AM
|To: '[EMAIL PROTECTED]'
|Subject: AW: JMSAppender in Container Managed Transactions
|
|
|I worry about one thing: As long as I do not roll back the
|contrainer
|transactions my listener MBD works really fine. But when I
|roll it back the
|onMessage() method of my MDB is not even touched. So, placing the
|acknowledgement whithin the method cannot be the clou.
|Are you really sure that (in a stateless session bean with
|trans-attribute=Required) you can do things like:
| try {
| <something transactional>
| } catch (Exception e) {
| someLogger.info("foo");
| ctx.setRollbackOnly();
| }
|
|If this works with WLS 6.1 it seems to me that BEA has
|garbled something on
|their way to 7.00.
|Anyway, I will try to get closer to your configuration
|(e.g. trying a queue
|instead of a topic).
|
|Thanks for your help
|Klaus
|
|
|
|> -----Ursprüngliche Nachricht-----
|> Von: [EMAIL PROTECTED]@GEHE
|> Gesendet: Freitag, 6. September 2002 15:53
|> An: [EMAIL PROTECTED]
|> Betreff: RE: JMSAppender in Container Managed Transactions
|>
|> 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]>
|>
|
|--
|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]>
