Hi, At first I thought you could simply use the vm transport as the first client to use it would boot an embedded broker. But then the brokers life time depends on that war. Also, I presume this could result in class loading issues at runtime?
The better approach seems to be deploying the broker as its own war. This introduces the problem of ensuring the broker gets started first but I would hope that Tomcat has a solution to offer. You can still stop the broker by stopping or undeploying the entire war file. Does it really need to be an embedded broker or could the broker also run standalone mode? You can then manage its life cycle completely independent of Tomcat. Regards, Torsten Mielke tors...@fusesource.com tmie...@blogspot.com On Dec 1, 2011, at 4:25 PM, Dysan wrote: > Hi, > > I'm working on a project where several war inside a tomcat 7 have to > communicate with a single embedded activeMQ (5.5.1) broker inside the same > Tomcat. > > I'm wondering what was the best practice to manage this and how to start and > stop the broker properly. > > Actually i try tu use a global JNDI entry in server.xml and in each war get > my activemq connection with a lookup. The first connection to the broker > implicitly starts it. But with this method I run into various problems like > instance already existing or locks in data store. > > Should I use instead an additional war which uses a BrokerFactory to start > the broker explicitly ? In this case how to make sure that this war executes > first in Tomcat ? And how do I stop my broker and where ? > > Thanks for the help. >
