How to Configure Tomcat root context

Tomcat has a horrible gotcha around the seemingly simple task of deploying a web-app to the so called “root context”, ie at <hostname>/<webapp>.

Either

  1. Define a ROOT.xml context file in conf/Catalina/localhost
  2. Name your webapp WAR “ROOT.war” or containing folder “ROOT”

(Note: I mean, literally, it must be named “ROOT”. Case sensitive)

Note that advice given in Tomcat docs and elsewhere on setting the context in <webapp>/META-INF/context.xml can be misleading: you cannot deploy to root context simply by using this setting.

Cause

The path attribute, which configures deployment to root context, is ignored outside conf/server.xml. See the docs for path attribute, especially 2nd paragraph. I think this was introduced with Tomcat 5.5.

Why is this poor design?

Well, it seems to run misdirect the “Convention over Configuration” principle that has proven so powerful in recent years. While inferring the context from the filename is a convention, the principle states that configuration should be optional and when present override the convention. In Tomcat’s case, the configuration (ie a “path” attribute) is silently ignored when specified.

The impact is that you must change your War filename or deployment folder, with resultant impacts on build processes & tools, just to vary its deployment URL – a form of inappropriate coupling. Even though there is a setting defined that would allow the artefact name and deployent URL to be decoupled.

I dont know what they were thinking…

Update: Is Glassfish v2 a better alternative?

July to October 2008, I trialed using Glassfish v2 instead of Tomcat, to run 3 small-medium Java webapps. Glassfish was pretty good, but I am now going back to Tomcat, as it seems the better overall option.

While I found the Glassfish Admin user-interface very convenient, the app-server proved slow and memory hungry compared with Tomcat. I also had problems getting virtual hosting to work properly under Glassfish.

I think the situation could change with Glassfish 3, currently in beta, as it is much more modular and can run webapps in a much more lightweight configuration.

Retooling for Scala

As an undergraduate at Melbourne Uni in the mid 90s, we mainly used C with vi on slow, ugly unix terminals. I thought it sucked.  When Java appeared on my radar in 96 I was in 3rd year, and I immediately jumped ship to get onto a higher-level, OO language. 12 years later, and I’d call myself a “native speaker” – Im familiar with almost every corner (and almost every shortcoming) of the language.

Anyway, Java’s weaknesses are well documented elsewhere, so I wont bore you. Ive been searching for the exit for some years, and have finally found my ticket into the next generation, something to get excited and inspired by, something worth comprehensively rewiring my brain for, something to love. Its Scala.

If at first you dont succeed…

I only got into Scala on my second attempt, and even then, the realisation of how good a programing language it is came only slowly. Now it rushes like a torrent in my head, opening new vistas and resetting expectations about how easy programming should be.

The first time, a year ago, its weird swiss-academic accent put me off; eg the name: type syntax, underscore wildcards._, Bottom Types, and the inability of the Eclipse plugin to auto-import like Java does. “Not for me”, I thought, “too strange and theoretical!”

So I followed Groovy, JRuby, C# and Boo instead. But none of them were right for me. C# and Boo dont run on the JVM. And the weak type systems in Groovy and JRuby is something I cannot comfortably swallow, because deep down I’m convinced types represent a fundamental programming truth, and thus should be modelled by the language.

…try, and try again

So I came back and made a second attempt at Scala. I bought Programming in Scala (which is a great beginner book) and I listened to an inspiring talk by Scala creator Martin Odersky. And gradually, I was able to see beyond the strange accent and appreciate that Scala delivers a cutting-edge, ultra-high-level, performant language thats widely usable in the real world, because its so thouroughly compatible with Java and the JVM.

If you’re considering Scala, realize its a very deep, very intelligently designed language. Like me, you might not grok it without considerable effort… but once you do, the rewards are worth it.