Embedded ActiveMQ Server within Tomcat 8 - tomcat7

I am trying to embed ActiveMQ Server within Tomcat 8 server.
For that I was following two tutorials available online.
https://isomorphic.atlassian.net/wiki/display/Main/Real-Time+Messaging+with+Tomcat+and+ActiveMQ
and
http://www.tomcatexpert.com/blog/2010/12/20/integrating-activemq-tomcat-using-global-jndi
In first tutorial changes were made only in $TomcatHome/conf/context.xml. But in second tutorial it was recommended to modify context.xml, server.xml and activemq.xml.
I follows both the tutorial separately one by one, also tried to use these with "Tomcat 7". But looks like both are not working for me.
With these changes, tomcat server starts without any issue no error in log. But Embedded ActiveMQ BrokerService is not getting started with Tomcat. Nothing is there in startup log for BrokerService.
Means there is no effect of these configurations on Tomcat Serve, and startup log is same with or without these configuration.
Am I missing anything in configuration for Tomcat 7 or Tomcat 8?
Why new JNDI Resource TAGs in configuration files is not getting picked by Tomcat?
Guys please help me.

I suggest looking at starting up ActiveMQ using the Spring XML bean configuration. Generally, you'll need/want to do some configuration of the broker and having the full XML is a simple way to manage that. I suggest looking at creating a simple war file that starts up a Spring beans.xml file. That file should just be the same contents as the conf/activemq.xml configuration. You then add all the JNDI resources as needed to point to the embedded broker.

Related

How to only auto configure the embedded container?

I'm trying bootify my app, which is XML configured. I'd love to have an embedded tomcat server that I can just run through the main method.
The simplest way to do it is to bootstrap the app using the existing XML config through #ImportResource("classpath:app-servlet.xml").
I cannot use auto configuration. We have certain circular dependencies that are not trivial to fix at this point.
The problem is that the embedded tomcat server only gets automatically configured if you use #EnableAutoConfiguration.
Is there a way to only auto configure the embedded server? I tried looking that Spring Boot's sources, namely EmbeddedServletContainerAutoConfiguration, including extending it and "running" it through my setup, but it only runs the customizers, not the ServletInitializer, therfore I'm getting an error "Root context already initialized".
Any help would be greatly appreciated.

Problems with setting up ActiveMQ on Tomcat with Flex, BlazeDS

As i have seen on one of forums, i'm "tomcat idiot". And, unfortunately, BlazeDS, ActiveMQ idiot too :(
I have big project, built with Tomcat, Flex 4, BlazeDS and Spring. Oracle is our database. As IDE we're using IntelliJ Idea 10.5.
At this time i'm trying to add messaging (JMS) to our project. I chose ActiveMQ as JMS provider for our system.
First of all, i tried to set up ActiveMQ for starting as standalone application (manual running of activemq.bat). For example of set-up, i used article of M.Martin
Than I tried to analyze problems and used ActiveMQ help about ActiveMQ and Tomcat tuning.
But nothing helped to me. After running our web app, i've got this error from flex:
[MessagingError message='Destination "message-destination" either does not exist or the destination has no channels defined (and the application does not define any default channels.)']
I can post here config files, that i've got as the result of my trainings.
I loaded them on free file hosting here

Not auto-starting webapp without servlet

I have a simple webapp deployed within Apache Tomcat (7.0.x) which is bootstrapped using a ContextLoaderListener instead of a Servlet. I would like this webapp to NOT auto-start whenever the Tomcat server itself is started but instead only started/stopped manually via the Tomcat manager. The examples I see online show how this can easily be done with the following code for servlets within web.xml:
<servlet><load-on-startup>0</load-on-startup></servlet>
But no examples are available for when using a ContextLoaderListener. Is this possible at all? Or would I need to include a servlet in order to configure the webapp to NOT auto-start whenever the Tomcat server itself is started?
Thanks in advance,
PM.
You should read this recent discussion on the Tomcat users' list which I believe answers your exact question: http://markmail.org/message/5hp3dohwj3vncg4c
The bottom line is that you can start only the Manager webapp on startup, but there are some restrictions about what happens after a restart. The replies from Mark Thomas are the most useful.
I don't think you will be able to do this in web.xml. load-on-startup is used to tell the webapp to start a servlet when the webapp is started. A webapp often consists of multiple servlets.
If you want to make sure the webapp is not loaded at startup, and instead use Tomcat manager to start it, I suggest you set deployOnStartup="false" in the <Host> container, in settings.xml. See the Tomcat 7 documentation page for the details:
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html

Can I set Tomcat's JNDI connection pooling settings in my Spring-MyBatis application?

Environment:
Tomcat 7
JNDI
Spring-MyBatis
No JTA - commons pooling only
Problem: Can't get the connection pooling to work as advertised. I can't find a single example of this that doesn't use a stand-alone Transaction manager or that doesn't put all the settings in the war, which makes JNDI pointless. I'm told that JTA is overkill for this application and that we should stick with commons pooling. That makes sense but I don't see a way to configure pooling, if we do it that way.
So... how do I configure connection pooling without putting the settings in the war file AND without using a stand-alone transaction manager? Can this be done without a full Java EE Application Server? We are just moving to Tomcat from another product which actually is full Java EE, so I am thinking this may be a Container vrs. Application server issue.
The weird part is that we can and have used JNDI but the pooling is definitely wrong.
Here is one example that probably works but why bother with JNDI if the settings are going to be in META-INF/context.xml?:
MyBatis JNDI Example
Even with context.xml, it's still a container level setting. But, it's a convenient way of deploying everything in a singe unit rather than having to create the connection pool before you deploy the WAR file.
JNDI is meant to keep your application configuration generic. If you take your WAR and deploy it in WebSphere, for example, it will ignore the context.xml file. But WebSphere will see that you have a JDNI resource-ref in your web.xml and walk you through creating the data source. Same idea as Tomcat, just a different way of doing it.
If you are 100% sure that this application will only run in Tomcat then you don't have to use JNDI. But, it will save you trouble later if you do move to another container.

tomcat: guvnor & webservice load order

I have guvnor deployed on tomcat 7. Now need to deploy a wrapper webservice around the BRMS. The webservice is a spring-ws and uses #Autowired kbase dependency injection. kbase is configured in spring-context XML as (not literal):
<drools:resource id="xxx" source="http://localhost:8080/guvnor/.../<package>/LATEST
Now the problem is tomcat first loads the webservice which fails to initialize as the guvnor URL is not up yet.
I can work around this by first starting only guvnor along with tomcat startup and then copy the WS war to the webapps folder. This works but is painful to do everytime.
What is the best approach?
I have seen this thread, but not sure if it will work in this context: Is there a way to enforce a deployment order in tomcat6?
Tried the following ways to address this:
Tomcat brings up both services on starup. The initialization of webservice fails but bring up the webservice manually through tomcate admin interface.
Use a script to do the same as above to bring up the webservice after a delay.
Change the drools package initialization to load through drools API instead of through config files along with a retry logic.
All of these work, but retaining the last option in the production code.

Resources