Java, Misc

Standard Maven : Multi-Module Maven Projects and Parent POMs


So you have a platform you are trying to make – most of it written using Java, maybe a little nodejs, zeromq or some other such goodies but you want to manage your java resources using as much out-of-the-box engineering to reduce overall boilerplate and headaches that come with a compiled language. You decide to go with maven because, well it’s better than JAR hell, and has more cool kids using it (github, etc). Tooling support is more than decent and you’ve got support by most if not all Apache projects for dependencies.


  • The system should be able to build the entire project and all dependencies in one go.
  • The system should be able to load the entire solution into an IDE (Eclipse)
  • The system should follow DRY and KISS – things should be in one place, and things should only do one thing and do it well
  • The system should be able to create a pit of success (proper documentation, unit tests, code coverage, reports, site creation, etc)


The example solution structure below is the same as that is used by Hibernate and some top level Apache projects.

 ./pom.xml            (solution level pom, glue for which modules are part of solution)
 ./modules            (all modules for the solution)
   ./core             (common shared lib, usually domain objects, etc)
     ./pom.xml        (standard maven module pom with ref to parent)
   ./api              (api for exposing jersey, jax-ws, jax-b services)
     ./pom.xml        (standard maven module pom with ref to parent)
   ./parent           (parent pom container)
     ./pom.xml        (standard parent pom)


Solution POM

The solution POM simply exists to setup the list of modules. Used primarily by build tools as well as IDE's this POM contains a listing of all modules that make up this solution. This combined with default properties and/or build profiles, default group id, packaging, etc.

Parent POM

Contains all common settings, build plugins, common libraries, frameworks, test tools, etc. Normally this includes all standards like custom repositories, which java version to target. Also common build dependencies such as junit, logging frameworks.

Finally the parent pom usually specifies the site generators, javadoc options, and team members, etc for site generation.

Module POM(s)

Specific to each logical component in the overall app/solution architecture. Normally separated out in classic N-Tier patterns - domain object module, business rule module, data module, api module, webapp module, etc.

Continuous Delivery

  • Enabled by applying top level code quality checks in the parent POM (checkstyle, PMD, etc)
  • Enabled by applying top level doc generation in the parent POM (JavaDocs, maven sites, etc)

Tomcat 6 & 7 – Best Practices


This guide shows you how to setup and run your Tomcat instances in a multi-tenant environment. It also shows you how to effectively design your provisioning, monitoring, and security model around Tomcat in a flexible manner.

The information in this guide is based on practices learned from customer feedback and product support, as well as experience from the field and in the trenches. The guidance is task-based and presented in the following parts.

  • Part I – Tomcat Overview – gives you quick overview of Tomcat as provided out-of-the-box by Apache, how it launches, and how it can be configured.
  • Part II – Security – gives you a quick overview of fundamental security concepts as they relate to Tomcat.
  • Part III – Configuration – gives you a quick overview of fundamental configuration options and concepts as they relate to performance, management, monitoring, and application configuration.
  • Part IV – Scenarios – gives you an overview of key scenarios with the use of Tomcat, with a focus on Intranet/Internet scenarios and clustering.

Scope of This Guide

This guide is focused on delivering a production ready strategy for large scale deployment of Tomcat in a sensible and extensible fashion into production environments. This approach can also be used on a local developer station (either Windows or Linux) to create a baseline.

Out of Scope

  • Java Language
  • Application Specific Scenarios

Why We Wrote This Guide

From our own experience with Tomcat and through conversations with customers and co-workers who work in the field, we determined there was demand for a guide that would show how to use Tomcat in the real world. While there is information in the product documentation, in blog posts and in forums, there has been no single place to find proven practices for the effective use of Tomcat in the context of line of business applications under real world constraints.

Who Should Read This Guide

This guide is targeted at providing individuals involved in building applications with Tomcat. The following are examples of roles that would benefit from this guidance:

  • A development team that wants to adopt Tomcat.
  • A software architect or developer looking to get the most out of Tomcat, with regard to designing their infrastructure, enhancing performance, and deployment scenarios.
  • Interested parties investigating the use of Tomcat but don’t know how well it would work for their deployment scenarios and constraints.
  • Individuals tasked with learning Tomcat.
  • A enterprise architect looking to promote the use of Tomcat in their line-of-business applications
  • Individuals tasked with automating the deployment of applications into Tomcat.

How To Use This Guide

Use the first part of the guide to gain a firm foundation in key concepts around Tomcat. Next, use the application scenarios to evaluate potential designs for your scenario. The application scenarios are skeletal end-to-end examples of how you might design your authentication, authorization and communication from a production Tomcat perspective. Use the appendix of “Guidelines”, “Practices”, “How To” articles and “Questions and Answers” to dive into implementation details. This separation allows you to understand the topics first and then explore the details as you see fit.

Part I – Tomcat Overview


  • Learn the basic requirements for Tomcat
  • Learn what is provided by Tomcat out-of-the-box
  • Learn how to start and stop a basic Tomcat instance


This chapter provides a set of foundational building blocks on which to base your understanding of Tomcat. Additionally, this chapter introduces various terms and concepts used throughout this guide.

Tomcat Minimum Requirements

Tomcat Layout

The keys to building a scalable tomcat solution includes the understanding of two key environment properties used by tomcat and what they mean.

  • CATALINA_HOME – represents the static files used by tomcat server such as the lib and bin directories.
  • CATALINA_BASE by default is set to CATALINA_HOME. CATALINA_BASE allows for the logical separation of tomcat and line-of-business applications.


This directory is never used during runtime. It’s sole purpose is to store scripts and to startup and shutdown tomcat along with resolve classpaths.

Contains the jars that make up Tomcat Server and any dependencies Tomcat server has.

By default a folder that does not exist when Tomcat is first downloaded. It is a reserved folder that when created allows for global level JARs to be placed and loaded by all Tomcat instances. It is best practice for JDBC drivers and any other classes that may utilize the J2SE 1.4 endorsed feature. In short, there are some package names from which classes are only loaded if the package files are located in the endorsed directory.


This directory contains configuration information for the specified application.

This is where you place your applications that run within TC. (defined by server.xml)

This is a server level working directory for your web applications. (defined by server.xml)

Runtime logs generated when you run tomcat. (defined by

This directory is used by the JVM for temporary files. (defined by


  • Intranet – Line of Business Web Application Server
  • Intranet – Line of Business Web Services Server
  • Internet – Application Web Application Server
  • Internet – Application Web Services Server

Intranet – Line of Business Web Application Server


You want to provide a means to host web based applications within your company. These applications are all require a Java servlet container and you wish to standardize the deployment, configuration, and hosting into a single unified platform of development. This includes the standardization of tomcat across the environments and the ability to support multiple lines of development with minimal impact to each business area.

Key Characteristics

This scenario applies to you if:

  • Operate within a corporate IT department
  • Need a standard Java servlet hosting environment
  • Are restricted by resources and/or skill-sets and need the simplest possible option
  • Need a means to have a stepping stone to more robust vendor solutions
  • Have many paths of development and many applications in different stages of development
  • Require occasional customizations of servlet containers and can not afford to offload work to individual teams
  • You need the ability to run multiple JVMs – largely because some teams and/or some applications may need to run on legacy JVMs and you do not want to restrict other teams or applications from using a newer JVM
  • You need the ability to run multiple versions of tomcat quickly and easily with a standard interface
  • You need the ability to run multiple versions of tomcat to upgrade without having to re-implement core configuration options.
  • You need the ability to upgrade to a vendor provided solution like springsource should the resources become available without additional effort.


Leverage Tomcat’s built in ability to separate the core Tomcat server from web application specifics through the use of the out-of-the-box provided CATALINA_HOME and CATALINA_BASE configuration options.

Intended Benefits

By implementing this solution the following benefits can be reached by the organization;

  • You may find that the separation of applications makes outages less painful and more granular increasing operational efficiency
  • A clear understanding of the environment makes communication across departments easier
  • Through standardization comes the possibility to create automated solutions for provisioning new application servers, increasing efficiency and reducing impacts to workers
  • By separating each application into it’s own container allows for finer grained performance tuning and customization of a particular application
  • Operations will now be able to effectively troubleshoot performance problems down to a particular application, memory leaks and performance and health metrics can be tailored and targeted to diagnose and resolve issues without impacting other parties.
  • Development efforts can happen in parallel with minimal impacts to other teams, shutting down and restarting a development or sqa server for a application only effects that application.

Possible Side Effects

By creating a script solution you may encounter the following smells;

  • Individuals or teams may start referring to their applications using specific port numbers rather than canonical names.
  • By allowing unlimited expansion the number of web applications may grow and the need for more hardware may be required
  • By making it easier to deploy applications you may forget application justification processes, always justify the creation of any new application or service, and always due buy vs. build analysis

Other alternatives

Buy vs. build analysis on cloud based solutions and/or vendor provided solutions like springsource tcserver.

Solution Implementation Details

To provide this solution to your organization download from the Apache the appropriate versions of Tomcat you wish to provide along with the JVM of your choice. We are going to assume the latest installation as of this writing which is Tomcat 7.0.14.

  1. Download Tomcat 7.0.14
  2. Create a new folder /opt/dev/tomcat
  3. Unzip apache-tomcat-7.0.14 into /opt/dev/tomcat
  4. Create a new file inside /opt/dev/tomcat
  5. Create a new file inside /opt/dev/tomcat
  6. Create a new directory /opt/dev/tomcat/shared – this will hold server wide configuration information
  7. Copy server.xml in apache-tomcat-7.0.14/conf to ./shared
  8. Copy in apache-tomcat-7.0.14/conf/ to ./shared

Provisioning a new Tomcat Instance

The convention used for creating a new tomcat instance is the creation of a new folder that contains the CATALINA_BASE core folder structure. This folder is given the same name as that of the port you wish Tomcat to use.

This allows for dynamically provisioning of a new Tomcat instances by simply creating the default CATALINA_BASE directory structure within a folder named the port number you wish to use.

By using this convention a system administrator can quickly understand what ports are being claimed by Tomcat and ensure there are no overlaps in port numbers. This also provides the capability that any startup/shutdown scripts will also pick up the new instance without the need to modify any /etc/init.d/ scripts so that any restart of the server will also pick up these changes.

Example – Provision A New Instance on Port 7051

  1. Create a new directory called /opt/dev/tomcat/7051
  2. Create the following directories [./bin, ./conf, ./logs, ./temp, ./work, ./webapp] inside 7051; mkdir -p /opt/dev/tomcat/7051/{bin,conf,logs,work,webapp,temp}
  3. Copy the default web.xml from your tomcat install directory cp /opt/dev/tomcat/tomcat-7.0.14/conf/web.xml /opt/dev/tomcat/7051/conf
  4. Optionally – create a new file inside ./7051/bin which will hold application specific customizations such a garbage collection options (see: example

Now the configuration and provisioning is complete you should be able to start tomcat:
/opt/dev/tomcat/ 7051 start

What remains is to deploy your application(s) to this tomcat instance by copying the wars to:

Automatic Startup/Shutdown of Multi Instance Tomcat

Enterprise applications need to have the ability to survive a restart of the server. By combining what you have now learned about tomcat and the new ability to run multiple instances you can now turn to the startup and shutdown of Tomcat using /etc/init.d.

  1. Create a new file in /etc/init.d called tomcat
  2. Run sudo chmod 755 /etc/init.d/tomcat
  3. Run /sbin/insserv -d tomcat

Fix Performance for SecureRandom creation of Sessions Taking Too Long

03-Jul-2011 20:33:19.272 INFO org.apache.catalina.util.SessionIdGenerator.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [68,810] milliseconds.

Problem is that it took 69 seconds for tomcat to startup because of the Session ID generation. This really isn’t acceptable and ignored by Sun as “not being a bug”.