You can refer to the following url as well. In one word it says that there is no mechanism or guarantee to control the load order of WAR for TOMCAT. http://efreedom.com/Question/1-6698646/Way-Enforce-Deployment-Order-Tomcat6
At 2011-12-02 17:24:10,"Torsten Mielke" <tors...@fusesource.com> wrote: >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. >> > > > >
