Ask the Experts : Apache/Tomcat 5.5 - Need someone who has good understanding of deploying war file/configuring context.xml

Current Products Installed - Windows 2008 SBS, Oracle 11d, Apache/Tomcat 5.5

3rd Party vendor came in, installed their package and it has been working for 8 months now, no installation notes available.

asked by


It is difficult to answer this question as there are still quite a few unknowns.  I'll will try to get you pointed in the right direction though.

First, when you say "It looks like it was successful but it is not", it is important to understand what is meant by "not successful".  Is the deployment failing?  For example, are you seeing any exceptions when the application is deployed? Any exceptions thrown during the deployment are major clues which would help you to understand what is wrong with the application.

Second, you mentioned that you are "deducing that the database connector is incorrect".  Again, it is important to understand what is incorrect about it?  Is the DataSource failing to connect to your Oracle database?  Are there any exceptions logged by the application?  Or is the query simply running, but not returning the expected result?  Some of these questions can be answered by looking at the log files, however it is also important to double check basics.  Is your database configuration is pointing to the right database?  Does that database contain valid data?  If that still does not help, try logging the queries that are being executed by the application.  Perhaps that can help to determine what is failing.

As for your additional questions...

Q.  If I could find out how the values in the live setup were specified in the original "deployment"
A.  You can simply look at your working installation.  The running web application would be deployed to the "webapps" directory.  The web.xml file would be located under "webapps/your-app-name/WEB-INF/web.xml".  The context.xml file is a little trickier as it could be located in a couple different spots.  The typical locactions would be "webapps/your-app-name/META-INF/context.xml", "conf/Catalina/localhost/your-app-name.xml" or just "conf/context.xml" (see below for more details).

Q.  understand how to retrieve these values from the live system
A.  If your live system is running with JMX enabled, you could connect to it with jconsole or jvisualvm and inspect the server and application's running configuration.

Q.  these values in the appropriate context.xml (seems like there is a hierarchical process of override)
A.  As I mentioned before, the "context.xml" file can live in a couple different places.  This is fully documented at the following link.

Hope that helps to get you pointed in the right direction.

answered by dmikusa on February 8, 2012 10:48 AM

Read More




Operations |

Blog : Apache Tomcat 6.0.35 Released

posted by Stacey Schneider on December 6, 2011 12:09 PM

The Apache Tomcat team announces the immediate availability of Apache Tomcat 6.0.35 stable.


Apache Tomcat 6.0.35 is primarily a security and bug fix release. All users of older versions of the Tomcat 6.0 family should upgrade to 6.0.35.

Note that is version has 4 zip binaries: a generic one and three bundled with Tomcat native binaries for different CPU architectures.

Read More



Developers, Operations | Apache Tomcat 6

Ask the Experts : How to create/modify global connection pool on the fly?

Is it possible to create and modify global connection pool on the fly?

I want do be able to deploy new applications using new global connection pool without restart tomcat. I don't want to use context.xml file in my applications.

The article shows how to create global connection pool configuring conf/server.xml file, but I don't know how to reflect change without restarting tomcat.

asked by persapiens


Is it possible to create new resources (as in <GlobalNamingResources><Resource .../></GlobalNamingResources>) at runtime?  No.  To create new global resources you need to modify "conf/server.xml" and restart Tomcat.

Is it possible to modify existing global resources?  It depends.  Some resources expose properties via JMX and those properties can be modified through jconsole.  If your resource exposes the properties that you need to modify then you should be able to update them at runtime.

Typically, when you need to be able to modify a resource without restarting Tomcat you would define that in your Context.  That way you can make changes to the Context, redeploy your application and see the changes all without restarting Tomcat.

answered by dmikusa on January 20, 2012 05:05 AM

Read More




Operations | global connection pool fly runtime

Blog : Apache Tomcat 7.0.23 Release

posted by Stacey Schneider on November 27, 2011 12:08 PM

The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.23


This release includes numerous bug fixes and several new features compared to version 7.0.22. The notable new features include:

  • The ability to start and stop child containers (primarily Contexts: i.e. web applications) in parallel which can significantly improve start times. This is disabled by default but can be enabled by setting the startStopThreads attribute of a Host to a value greater than one.
  • Cache the results of parsing the global and host level context.xml files to improve start times.
  • Improve the handling of failed deployments so that a broken application can be fixed (e.g. via JMX) and another attempt made to start it rather than it having to be removed.

Please refer to the change log for the complete list of changes:

Read More



Developers, Operations | Apache Tomcat 7

Blog : Performance Tuning the JVM for Running Apache Tomcat

posted by dmikusa on November 22, 2011 09:13 AM

This article is the second in a series discussing how to performance tune the JVM to better run Apache Tomcat. In the first article, we discussed the basic basic goals and how to monitor the performance of your JVM.

If you have not read the first article, I would strongly suggest reading that before continuing with this article. It is important to understand and follow the processes outlined in that article when performance tuning. They will both save you time and prevent you getting into trouble. With that, let's continue.

Tuning the JVM

At this point we've covered the basics and are ready to begin examining the JVM options that are available to us. Please note that while these options can be used for any application running on the JVM, this article will focus sole only how they can be applied to Tomcat. The usage of these options for other applications may or may not be appropriate.

Note: For simplicity, it is assumed that you are running an Oracle Hotspot JVM.

Read More



Developers, Operations | Tomcat Configuration, Tomcat Performance

Blog : Setting Up Measurement of Garbage Collection in Apache Tomcat

posted by dmikusa on November 16, 2011 08:15 AM

Have you ever seen this scenario before? A user has deployed an application to a Tomcat server. The application works great during testing and QA; however, when the user moves the application into production, the load increases and Tomcat stops handling requests. At first this happens occasionally and for only 5 or 10 seconds per occurrence. It's such a small issue, the user might not even notice or, if noticed, may choose to just ignore the problem. After all, it's only 5 or 10 seconds and it's not happening very often. Unfortunately for the user, as the application continues to run the problem continues to occur and with a greater frequency; possibly until the Tomcat server just stops responding to requests all together.

There is a good chance that at some point in your career, you or someone you know has faced this issue. While there are multiple possible causes to this problem like blocked threads, too much load on the server, or even application specific problems, the one cause of this problem that I see over and over is excessive garbage collection.

As an application runs it creates objects. As it continues to run, many of these objects are no longer needed. In Java, the unused objects remain in memory until a garbage collection occurs and frees up the memory used by the objects. In most cases, these garbage collections run very quickly, but occasionally the garbage collector will need to run a “full” collection. When a full collection is run, not only does it take a considerable amount of time, but the entire JVM has to be paused while the collector runs. It is this “stop-the-world” behavior that causes Tomcat to fail to respond to a request.

Fortunately, there are some strategies which can be employed to mitigate the affects of garbage collections; but first, a quick discussion about performance tuning.

Read More



Developers, Operations | Tomcat Configuration, Tomcat Performance

Blog : A Finer Point of Apache Tomcat Valves

posted by chanthing on November 10, 2011 10:09 AM

1. Introduction

Valves have been an integral feature of Apache Tomcat since version 4 was introduced over seven years ago. As their name suggests, valves provide a way of inserting functionality within a pipeline, in this case, the Tomcat request / response stream. One simply writes a subclass of org.apache.catalina.valves.ValveBase or a class that implements the org.apache.catalina.valves.Valve interface and then adds an XML element with the valve’s classname to the appropriate configuration file (in most classes as a sub element of Engine in server.xml). Then, at some point (we’ll come back to that) in the processing of a request, your valve’s invoke method will be called. The invoke method gets passed both the Request and the Response objects, and is free to do whatever it likes with them (though having the power doesn’t mean it’s a good idea to use it).

You may be familiar with this paradigm through servlet filters used by web applications to do application-specific processing of the request / response pipeline. The key distinction between servlet filters and Tomcat Valves is that Valves are applied and controlled through the configuration of the application server. Depending on the container definition where the Valve element appears in the Tomcat configuration, the valve could be configured for all applications on the application server, a subset of applications, or even a single application (by locating the Valve element within a given Context).

This is a simple powerful model that has been written about extensively. A Google search on “tomcat valve” turns up a multitude of descriptions, examples, and “how tos”. The Reference Page on “The Valve Component” that ships with Apache Tomcat 7 documents the mechanism thoroughly along with descriptions of the valve implementations that ship by default. So why yet another article on the subject? What do I hope to add to the canon?

The effort started simply enough: The plan was to demonstrate the configuration and use of the ThreadDiagnosticsValve that ships with VMware’s vFabric tc Server, a commercial application server based on Apache Tomcat. Additionally I would write and configure a custom Valve, in this case, a valve to exercise tc Server’s ThreadDiagnosticsValve so that I could demonstrate its use and effects without actually having to have a misbehaving application to trigger it. Not exactly Nobel material, but I thought it would be a useful adjunct to the existing documentation and an interesting exercise.

However, it didn’t go exactly as planned and looking at the reason it didn’t is probably as helpful in understanding Tomcat Valves as the original exercise.

Read More



Developers, Operations | Tomcat Configuration, Tomcat Performance, Tomcat Valves

Blog : Best Practices for Securing Apache Tomcat 7

posted by mthomas on November 2, 2011 07:27 AM

Every effort is made to have each version of Apache Tomcat to ship with a system of reasonable defaults forsecurity purposes. This means that the standard defaults for the security settings are reasonably secure—it is not as secure as it could be, but not horribly insecure either. The default security level is essentially a compromise between security and usability. It is probably OK for simple use in production, but there are a number of things that all users should consider before deploying business applications on a standard installation of Apache Tomcat.

General precautions:

  • Tomcat security configuration should not be your only line of defense. Take a comprehensive look at security and ensure that your OS is secure,there are firewalls in place, and file permissions are set correctly as well.Remember, it won’t matter how secure your application is if your underlying platform is vulnerable. A simple rule of thumb (especially for those firewalls) is to ban everything and only explicitly allow what access you need to run your applications.
  • Delete all the stuff you don’t need. Tomcat will by default install a handful of default applications that you don’t need, and having them in production is just more applications to look after and to ensure are secure. Take a look at the documentation, examples, default root web application, Manager App and Host Manager App and if you are not using them, delete them and focus just on your production applications. While these applications are relatively low risk, eliminating risk is always a better strategy. Same would be true if applications are archived or no longer in use – move them off of the production site to eliminate any additional pathways for threats.
  • Consider running under a Security Manager. This is always a good idea if you are running applications that you do not trust (e.g. a hosting environment), or if you want an additional layer of protection. A Security Manager will essentially run each deployed web application in a separate sandbox to prevent malicious code from accessing your files or other applications on your network. While it is always a good idea to run under a security manager, it should be noted that this is best done during early stages of development as it can impact how an application behaves and thorough testing is always recommended. For later stage projects you’llneed to evaluate if the benefits of a security managerare worth the extra cost of development and testing to deploy it properly. The TCK tests that are used as part of every Tomcat release are always run under a Security Manager but few users run with a Security Manager in production. There is, therefore, a slightly increased risk that you will hit a Tomcat bug running with a Security Manager. However, it is usually possible to configure around such bugs if they occur.

Read More



Developers, Operations | Tomcat Configuration, Tomcat Security

Blog : Understanding Apache Tomcat: Getting Started

posted by fhanik on October 19, 2011 07:39 AM

Apache Tomcat, and other containers, have been around for so long today that it has become increasingly harder to get started with them today.

In this article, we will take you back from the beginning with how to get started with Apache Tomcat. We will go into the lowest level, so you don't have to rely on an IDE or other system to get started. This article is written for those that have never used Apache Tomcat and wish to get started in an easy, yet explanatory, way that helps you to understand what is happening under the hood. This will fast track you to become very proficient with this light weight application server.

Step 1. Download and Install Apache Tomcat

While there are a lot of different packages available to install Tomcat, for example some Linux distributions you can download it using that distributions package and dependency management. This is good, for the sake of simplicity, but once again, you lose the concept of what Tomcat is and what true dependencies it has as well on how to use it.

I strongly recommend only moving to a third party packaging of Apache Tomcat after you understand the container itself. This will help avoid complications when you try to create a plan for how you distribute, upgrade and maintain your software.

Rule 1. When learning, only download the software from

Now, since you are learning Apache Tomcat from scratch, I suggest you start with Apache Tomcat 7.  As explained in an earlier post,  the majority of features that are implemented, are driven by the (Servlet) and (JSP) specifications.  Each time the Servlet specification is upgraded, new features added, the Apache Tomcat will plan for a new major release of Apache Tomcat. The latest version, Apache Tomcat 7,  is based on the version of the Servlet specification, in this case, Servlet 3.0.

Read More



Developers, Operations | Apache Tomcat 6, Apache Tomcat 7

Blog : How to Use Fragments and Annotations To Configure Your Web Application

posted by mthomas on October 11, 2011 09:10 AM

The Servlet 3 specification - implemented in Apache Tomcat 7 - allows web.xml fragments and annotations to be used to specify configuration information for a web application. This means that, instead of packaging up every configuration centrally in your web.xml file, every JAR can have its own xml fragment containing its own little bit of configuration for whatever classes are in that JAR. This makes it easy to add support for packages with very little effort. For instance, a Spring developer would no longer need to add the Spring application context to the web.xml file, rather they could take advantage of a web fragment in the Spring JAR that would automatically add this configuration information at runtime.

Annotations take this one step further, and allow developers to annotate code that dynamically configures application components such as Servlets and Filters. Java libraries and frameworks have been embracing annotations for some time. In fact, several IDE’s these days use annotations as a default, adding the @WebServlet annotation by default when you create a new Servlet in a dynamic web project.

Performance Impacts

Both annotations and web fragments will impact performance, particularly at application startup. Tomcat has to scan every class in every single jar file to detect if the class has been annotated as a Servlet, a Filter or Listener. This can add substantial time to application start up, which is not so much of a problem for production applications as they should start very infrequently, but it can be pretty problematic during development when you are repetitively restarting.

Tip: If you are not going to be using annotations or web-fragments, you should set your metadata-complete to true in your web.xml file to avoid the longer start up time. (web-app metadata-complete=""true"").

Read More



Operations | Tomcat Configuration, Apache Tomcat 7

Syndicate content