activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From uma...@comcast.net
Subject Re: Sharing embedded broker across webapp contexts
Date Mon, 18 Jun 2007 18:44:41 GMT

Mario,

Thanks for the explanation.  If I incorporate the JNDI configuration of amq,
would Tomcat automatically start the broker? I need to create an embedded
broker with network connectors. If I specify xbean configuration in JNDI,
would Tomcat automatically create the broker and issue broker.start()?

Thanks,

/U 

 -------------- Original message ----------------------
From: "Mario Siegenthaler" <mario.siegenthaler@gmail.com>
> I think the easiest way would be to use a broker that is started by
> tomcat. This can be done using JNDI-configurations in the tomcats
> server.xml (see http://activemq.apache.org/tomcat.html).
> To connect to the broker you can either get the connection-factory via
> JNDI (standard way) or just make a new ActiveMQ connection factory
> pointing to vm://localhost (or whatever you named your broker).
> You'll need to put the active-mq jar into the common/lib (or into the
> server/lib if you only use jms-api functions and have the jms api with
> common/lib) of your tomcat. Also you have to make sure that you don't
> include a jms-api or activemq-jar in your war as that would cause the
> feared ClassCastException.
> 
> If you don't like the way I described above then you can also just put
> the AMQ-jar in the common/lib (and not in any of the webapps) and
> create the connection factory in each webapp for vm://localhost. This
> will bring up a broker if there isn't already one running, so I
> doesn't matter which webapp starts first. You'll not need any special
> setup code. However I'm not sure where I'd put the activemq.xml
> configuration file in that case.
> 
> However I'd strongly recommend the first proposal, since it seems more
> controllable and easier to configure.
> 
> To your point 2: The class is serialized when it's passed around by
> the broker (except you turn it off, of course only possible in the
> vm-protocol). So you'll just have to make sure the thing is compatible
> and you can put the jar X's in into both webapps and you don't need it
> to put into common/lib.
> 
> 3) No, I don't see any (technical) reason. However I'd recommend to
> 'inject' the connection factory into the webapp, so the webapp is
> completely agnostic to whether the broker is embedded or not. Else
> you'll have more trouble moving them around.
> 
> Mario
> 
> On 6/18/07, uma_rk@comcast.net <uma_rk@comcast.net> wrote:
> >
> > I am using activemq 4.1.1 on JDK6 with Tomcat 5.5.x.
> >
> > I have a couple of webapp contexts in a servlet container that use activemq 
> broker.
> > I have been using an external broker but would like to embed the broker in the
> > servlet container. I have the following questions.
> >
> > 1) Assume I have webapps A and B. Is it necessary that only one of the two 
> webapps
> >    assume the responsibility of starting the broker? I mean, I would like to 
> embed the
> >   starting of the broker in a jarfile that is shared by both the webapps. Its 
> hence easy for me
> >   to keep the jarfile agnostic to which webapp its operating in and execute 
> the broker start code
> >   at context startup.
> >
> >   Stated simply, would this sequence cause two different brokers to attempt to 
> start?
> > Should I build mechanisms to make sure the broker.start() is executed only 
> once?
> >
> >      Webapp A:
> >             context load { // Time t
> >                  Broker broker = new broker("tcp://localhost:61616"); 
> //pseudocode
> >                  broker.start();
> >             }
> >
> >         Webapp B:
> >             context load { // Time t + 5
> >                  Broker broker = new broker("tcp://localhost:61616"); 
> //pseudocode
> >                  broker.start();
> >             }
> >
> > 2) Assume webapp A starts the broker. Also, let's say Class X is defined in a 
> jarfile
> >   common to both the webapps.
> >
> >    Would this cause class cast exception if webapp B received an instance of 
> class X
> >    from the broker? (since I assume the broker would use the webapp A 
> classloader
> >    to load class X)?
> >
> >    If so how do I avoid this class loading issue? Do I need to place the 
> activemq jarfiles
> >    as well as the application jarfiles which contains classes of the messages 
> dispatched
> >    over activemq to be in a shared system classpath common to both the webapp 
> contexts?
> >
> > 3) In a setup such as this where multiple webapps share the same embedded 
> broker,
> >    is it mandatory that they use an external broker?
> >
> >     What are the other gotchas in using the embedded broker in this fashion?
> >
> > Regards
> >
> > /U
> >


Mime
View raw message