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 19:27:18 GMT
 
Mario,

How do I specify the network connector in the JNDI configuration?
Is there a way to point Tomcat to the xbean configuration for the broker
instead of replicating the configuration element by element? I use the
xbean config file to specify the JMX configuration, ceiling on the memory footprint,
the destination policies and finally the network connectors.

       <Resource 
                name="jms/ConnectionFactory" 
                auth="Container"
                type="org.apache.activemq.ActiveMQConnectionFactory" 
                description="JMS Connection Factory"
                factory="org.apache.activemq.jndi.JNDIReferenceFactory" 
                brokerURL="tcp://localhost:61616" 
                brokerName="MyBroker"
       />

Could someone point me to a complete JNDI configuration for an embedded broker?
The activemq site has a lot of  fragments of useful nuggets but I am unable to find a 
full configuration for examples...

Regards

/U



 -------------- Original message ----------------------
From: uma_rk@comcast.net
> 
> 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