For what it's worth (James' solutions are probably better)... if you need
'random' access to queues from jboss (or any JNDI enforced thing), you can
create your own JNDI context (javax.naming.Context) and bind that to some
spot in the jboss jndi tree, then all you do is override Context.lookup(name)
to return a new Queue('name')example, in our case, our queues are in the form of 'work.queue.[SOME QUEUE NAME]' and we bind out context object to /jms/auto/queue then in the MDBs (ejb3 MDB) we just set the queue jndi name to "/jms/auto/queue/work.queue.blah" keeps us from having to define the queue in some kind of jndi binding tree in addition to the (required) MDB setting. Like I said, James' solution is probably better, but if you are stuck using MDBs, there's really no alternative since the spec requires JNDI bindings for the destination. On 5/23/07, James Strachan <[EMAIL PROTECTED]> wrote:
On 5/23/07, sbuberl <[EMAIL PROTECTED]> wrote: > > > > James.Strachan wrote: > > > > On 5/23/07, sbuberl <[EMAIL PROTECTED]> wrote: > >> > >> Hi. > >> > >> My server posts live highway traffic accidents and events to topics, but > >> most messages are only updates on existing event data. So I set up my > >> server > >> to monitor when a client logs in/out and sends them all live events in > >> one > >> message. I can't use durable subscriptions on topics because that would > >> send > >> them lots of old data as well when my subscribers only want the live > >> data. > >> > >> I successfull intergrated activeMQ with JBoss and I have beans monitoring > >> when a client logs in/out and when they create a consumer on the event > >> topic > >> with my database. All updates get sent to the following virtual topic: > >> <virtualTopic name="ATIS" prefix="Consumers.*." /> > >> > >> The problem is: how can I retrieve the queue to send to with JBoss? > > > > Given your requirements, you probably don't want to use a queue per > > client as you only want live messages being sent. Virtual topics & > > queues work like durable topic subscribers. > > > > I'd recommend just using a Topic with non-persistent delivery of the > > messages > > > > -- > > James > > ------- > > http://macstrac.blogspot.com/ > > > > > > Thanks for the advice on switching off virtual topics. I was fine with one > topic before, but I switched to virtual topics and queues because I still > need to have each client have its own queue/topic in order to send a logging > in client a "refresh" message (as stated before, a single message of all > live events in one message). There's a cooler solution. You can send individual initial messages to consumers via topics using the subscription recovery policy and a custom initial message query... http://activemq.apache.org/subscription-recovery-policy.html basically as a topic subscription starts you have the option to send one or more intiial messages. You just use this http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/broker/region/policy/QueryBasedSubscriptionRecoveryPolicy.html and then provide your own implementation of http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/broker/region/policy/MessageQuery.html which can just create the initial refresh message(s). i.e. you could support some kinda 'last image caching' type thing where the consumer receives the last stable state first before any future updates > So if I switch to regular topics, I'm still > stuck in the same boat of binding each client topic to JBoss JNDI? There's only 1 topic for all clients; so 1 JNDI entry (if you use JNDI - personally I try and avoid it at all costs & use Spring or Java code instead :) -- James ------- http://macstrac.blogspot.com/
