Specify context name in Tomcat

When developing web applications that are distributed as WAR files running in Tomcat most of the times you want to be able to specify the context name to a nicer name than Tomcat provides by default. Which is the name of the WAR file itself. When i.e. you are keeping the version within the name of the WAR this will result in some weird name like myapp-1.2. This is most of the times not what you want.

Most of the times you want a nice context name like myapp without the version in it. According to the Tomcat documentation you can do it in 3 ways:
  1. Edit the server.xml
  2. Add a context.xml to the $CATALINA_HOME/conf/Catalina/localhost with the name of your context.
  3. Add a context.xml to your META-INF directory in your WAR file
The first two options just work fine only the last one doesn't do the job for you for some reason.

Personally the second option is the best option since it's not intrusive to your application and also not to Tomcat since you leave the server.xml alone. This way you define the context name in a separate configuration file and enables you to also keep the environment specific configuration out of the application. You can than simply provide this configuration file in a distribution package for installation. Another benefit is that you provide yourself with more flexibility since you can easily switch to EAR file distribution when running on an application server. On an application server you define your context within your EAR file which will only effect your distribution project and not your application.

So why would you put a context.xml in your META-INF directory in your WAR file? Well it can be useful if you just want to expose some application specific JNDI resources for your application.

So how can I achieve this? Here is a link to the Tomcat documentation where you can find out what exactly you should do to achieve this.
http://tomcat.apache.org/tomcat-4.1-doc/jndi-datasource-examples-howto.html


Comments

Post a Comment

Popular posts from this blog

Fastest XML parser

In most applications you need to do some XML parsing to either provide XML to external systems or parse XML from external systems or of course both. Since the systems I work on use a lot of XML and they need to be as fast as possible I did some tests on several XML parsers. I tested the following parsers/XML frameworks: JDom Piccolo StaxMate XStream JAXB 2.1 All parsers were tested in isolation with the following parameters: 25 threads running simultaniously Every thread calls the parser 100 times The results are as follows. JDom Avg. parsing time: 325.24 ms Avg. memory usage: 307 KB Piccolo Avg. parsing time: 88.08 ms Avg. memory usage: 454 KB StaxMate Avg. parsing time: 96.16 ms Avg. memory usage: 203 KB XStream Avg. parsing time: 77.04 ms Avg. memory usage: 319 KB Jaxb 2.1 Avg. parsing time: 1778.12 ms Avg. memory usage: 618 KB As you can see XStream is the fastest one of them all. The total ranking of the parsers you can find below: XStream Piccolo StaxMate JDom JAXB 2.1
Read more

Tomcat behind Apache HTTP server using Spring Security

Since I have been struggling with applications not working properly behind Apache HTTP server that use Spring Security I dedicated this blog to this issue. When you develop an application using Spring security this works fine when just running on a Tomcat server e.g. http://localhost:8080/app-context/. The problems start when you want to setup your environment properly by adding an Apache HTTP server in front of it using proxy AJP. You would start by adding the following to your apache config file: ProxyPass /app-context/ ajp://localhost:8009/app-context/ This works fine when trying to go to http://servername/app-context/ but when you try to login you will be redirected back to the login page everytime. To avoid this behavior you need to add the following line to your Apache configuration: ProxyPass /app-context/j_spring_security_check ajp://localhost:8009/app-context/j_spring_security_check For some reason it doesn't work without this line which seems weird to me since you basical
Read more

Cargo-itest open source project

I recently started an open source project called cargo-itest. This was started up because when I worked on several projects I needed to create integration tests for them which all had similarities. I was previously doing it with the maven2 cargo plug-in but wasn't really fond of it because it most of the times didn't work and when it worked it stopped working after editing the configuration. In other words it was very unstable. This initiated me to start to use the java API of Cargo instead of the maven plugin. By using the java API it already removes the dependency from your build system in this case Maven. Having no dependency on the build system gives you a couple of advantages: You can run it in any IDE that supports JUnit. You can switch easily to another build system without changing your tests and test configuration. These are general advantages of just using the API but also part of using my open source project cargo-itest. This project enables you to easily start creat
Read more