• Post Reply Bookmark Topic Watch Topic
  • New Topic

MDB HELP: Getting EJB-NAME or Queue used from a MDB?  RSS feed

 
Dave Turkel
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I'm trying to create a dispatcher-type framework using MDB's.
I have a single MDB class (SimpleMDB), which I have configured to listen to multiple Queues, using different EJB Names for those queues.
This mechanism works fine-- messages come in and execute the single onMessage() method regardless of queue.
NOW- I need to find out either the configured EJB Name ("ejb-name" in the descriptor), or the queue name the message came in from to do my dispatching logic.
Anyone have any ideas???
Thanks,
David Turkel
 
john smith
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1) pass the ejbname as part of the message
2) split things out so 1 MDB listens to 1 queue.
 
Dave Turkel
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the reply. I do appreciate it, but it's not really what I'm looking for:
Placing the EJB-NAME as part of the messsage is a non-optimal solution as far as I'm concerned-- the message should be completely devoid of anything programmatic.
Creating new beans for each queue doesn't make sense because the MDB is only a receiver, and should be allowed to be used generically to listen to multiple queue's/topics-- delegating transactions to appropriate business beans/classes.
Anybody have other thoughts on how to accomplish this?? Is there nothing in the Context that I can use?
 
Philipp Huber
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave,
I have the same problem, multiple queues on which one MDB should listen. So far I thought on listener per EJB.
Could you please explain how you did this?
'I have a single MDB class (SimpleMDB), which I have configured to listen to multiple Queues, using different EJB Names for those queues.'
Philipp
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, I have done something very similar to what I think you are trying to accomplish. My solution was based completely on having a single destination Topic with multiple subscribers. This removed the need to "hard-code" destination logic in the sender code since all messages were sent to the same destination and allowed multiple subscribers to consume the same JMS Message.
To properly route messages I used JMS properties to identify message types, which were set by the sender. The subscribers (MDBs) were configured with message selectors to filter only the messages types that they were interested in.
Overall, the solution worked liked a charm and was very flexible to changes. New message types and/or subscribers didn't require the creation of JMS resources.
 
Ade Barkah
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave,
Given your setup, perhaps the easiest way is to configure an env-entry for each bean. The class can then lookup the env-entry.

Then your bean can do something like:

Generally though, if possible you're better-off marking the message with some (business-related attribute) you can switch upon rather than using multiple queues. For example, in one project we used MDBs to dispatch various batch processes. So we marked each message with its related batch process, allowing the MDBs dispatch based on that property, regardless of the configured ejb or queue name. MDBs across the cluster fetched from a single distributed queue, and we didn't need to configure a new bean & queue (and error queue) everytime we needed a new function.
Regards,
-Ade Barkah
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!