What type of Java app server should you choose for your next project? Well, that kinda depends on what kind of app you’re building, what your needs are, what type of organization you work in, and lots of other factors too. Hence the debate. So perk up your ears, and get ready for a showdown.
This blog post continues the Great Application Server Debate series, in which we have already covered IBM Liberty Profile as well as Jetty. Today we’re talking about (arguably the most popular application server) Tomcat and also touching on TomEE. As with previous posts, we will be reviewing the application server purely from a developers point of view.
Apache Tomcat is an open source application server that (in version 7.0) implements the Servlet 3.0 and JavaServer Pages 2.2 specifications, and includes many additional features that make it a useful platform for developing and deploying web applications and web services.
The world of app servers has traditionally been split between servlet-based containers and enterprise (Java EE) servers, with Tomcat being the clear winner in the servlet-based container space and WebSphere and Weblogic sharing the Java EE mantle. Typically servlet-based containers are used significantly more than Java EE servers, almost 60% of the respondents to our survey use at least one servlet-based container. Below you can see last year’s Developer Productivity Report results on Application Servers:
In the last half of 2012, the big dogs were trying to become more nimble and agile, while the quick Tomcats of the world are trying to add more of the Java EE feature set. The addition of the Liberty profile to the WebSphere line of products represents a shift in the mindset of traditional enterprise users, and developers are clamoring for a faster way to get as close to a production environment as possible on their local machines.
I was brainstorming in the shower the other day, and I thought “Eureka!” – I need to bootstrap and test my Java app on a dynamic cluster with 800 Tomcat servers right now! Then, breakfast.
Obviously, every now and then you need to build a dynamic cluster of 800 Tomcat machines and then run some tests. Oh, wait, you don’t? Well, lets say you do. Provisioning your machines on the cloud for testing is a great way to “exercise” your app and work on:
Digging into data searching for insights is always an exciting activity. Last year’s Java EE Productivity Report was focused on tools/technologies/standards in use (exclusive selections) and turnaround time in Java (i.e. how much time is spent per hour redeploying/restarting).Read more
Operations teams love LiveRebel because it helps bring Continuous Delivery practices into reality, letting them sleep soundly at night. Far too often applications in production are updated manually at 3 AM by overworked operations staff, so as not to affect customer usage sessions. And if something breaks, LiveRebel was designed to bring high levels of automation and predictability to customers’ deployment pipelines, enabling them to commit production updates that are online, automated, transactional and 100% reversible via “panic button”. Plus, they deploy new versions during the day, with all staff available, in case something breaks.Read more
When a developer using JRebel wants to begin a multi-module project in IntelliJ IDEA, the default settings create a situation where rebel.xml files override each other. This means that JRebel is unable to detect all the classes in the project (meaning = it cannot work its customary magic). In this post, we’ll do a technical deep-dive into what happens when the default setup is used, how it works and what to do to work around the defaults so that JRebel can detect all classes in the project and eliminate the need to restart for making changes to them.Read more
These results are preserved for comparison, but see the later report for a full analysis of the completed survey.Read more
