Java EE 7 includes many exciting new specifications — one of special interest to my team is the introduction of the Batch Processing (JSR 352) specification, as we have been doing lots of
Spring Batch work lately. So I thought I would share how Spring Batch and Java EE 7 Batch processing compare.
– non-interactive, long-running, bulk-oriented processing
– computationally intensive processing
– option for sequential or in parallel executions
– run ad-hoc, scheduled or on-demand executions
I recently found a good article which summarizes/compares the strengths of two key players in Integration Framework development (Open Source).
Working through an integration project for a client we encountered an issue with Tomcat not being able to start our Grails application which housed our Apache Camel integration routes.
When we started tomcat it would throw a “SEVERE: Error listenerStart” error.
The problem was there was no way of narrowing down the error, as Tomcat wasn’t outputting the root cause of the exception.
- Grails 2.0.4
- Tomcat 7.0.34
- Java 1.6.0_43
After tomcat explodes out the war file
- stop tomcat
- go into the following dir <tomcat dir>/webapps/<appname>/WEB-INF/classes
- add a file called logging.properties with the following content below
- start tomcat
- should see root cause in logs/<appname>.log
handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler org.apache.juli.FileHandler.level = FINE
org.apache.juli.FileHandler.prefix = <appname>.
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
Real Time Saver…
I was recently on a consulting engagement and requested to make modifications to a high volume JMS implementation (over 14 million messages per day). One of the tasks was to onboard/integrate a legacy system to the enterprise messaging system. One of the requirements was to attach two additional message headers as follows (in order to support an audit process already in place):
- Date in which the Message was published to the system (format “2013-01-20″ [String])
- Time in which the Message was published to the system (format “15:57:31″ [String])
The bridge to the messaging system is multi-threaded, so I needed to find a thread safe way of getting both the Date and Time formatted to the outlined requirement. As most java developers are aware SimpleDateFormatter is NOT THREAD SAFE!
After some quick looking and trying I ended up with the following:
I recently worked on a Spring based project, and was tasked with identifying where the bottleneck was within a set of service calls. So I utilized the Spring StopWatch implementation to help isolate the issue(s).
This blog entry will provide you with a high level understanding of what the Spring StopWatch utility has to offer.
Heres how I did it…
1. First off I create a Java Project
2. Next I add Spring and Groovy Support to the Project
I am adding the Groovy Language support, so I can keep my code as simple and clean as possible (no need for try/catch, semi-colons, etc…). Note: you can implement this code in pure Java!
3. Next I make my new Groovy Class
5. Next write the implementation code
- import org.springframework.util.StopWatch
- setup the service calls I want to test (repeat as needed)
6. Run the Code and View the output
7. Now taking this to the next level would be to incorporate what I have demonstrated within this post with Spring AOP