techblog 

This is one of those things that seems to be easy enough, but finding out exactly how to do it is not easy. So I thought I would try and document it in a straight forward way.

When you run a web based application that runs in Tomcat then the URL looks something like this

http://www.example.tld/servletname/pageyouwanttovisit

The servlet name is important to Tomcat because it tells it which servlet to send the page request to. In other words, this way you can have many different servlets on the same server and the /servletname/ part tells Tomcat which request goes where. One day we will all switch to IoC containers like Spring and this crude URL-based mechanism will be disappear.

However until then you have the problem that you end up with the servlet name appearing in every URL, which is quite often not relevant to your site and something you would prefer is not there. Especially you have a site that only runs one servlet. For example this blog is delivered via Blojsom but we don’t want that leading to a /blojsom/ appearing in every URL. What we want is something that looks like this:

http://www.example.tld/pageyouwanttovisit

To do this you need to edit the .xml content file for that servlet, which can be found in (Tomcat 5 and above):

$CATALINA_HOME/conf/engine/host/servletname.xml

So if you were looking for this file for the servlet infoglueDeliverLive on a standard Tomcat install, then it would be found as

$CATALINA_HOME/conf/Catalina/localhost/infoglueDeliverLive.xml

Inside that file is the context tag, which tells Tomcat what URL part to link to the servlet. For the same example the opening part of that tag looks like this:

<Context path="/infoglueDeliverLive" docBase="/usr/local/jakarta-tomcat-5.5.7//webapps/infoglueDeliverLive" debug="0" reloadable="true" crossContext="true">

So to get rid of the need for the servlet name in the URL you just set the path attribute to an empty string (the root context). In this example the whole opening part of the tag then looks like this:

<Context path="" docBase="/usr/local/jakarta-tomcat-5.5.7//webapps/infoglueDeliverLive" debug="0" reloadable="true" crossContext="true">

And that is all. To make it even easier, this is hot-deployable - you do not need to restart Tomcat for it to take effect.

Over the past few weeks, I have been building a central syslog server. I wanted this log server to be very reliable and never lose any log messages. There are two ways I could protect against failure of the log server: first, was to have 2 syslog servers and send all the logs to both of them. Then each night to run some kind of reconciliation script to merge the logs into one. The other option was to run a single syslog server on a cluster. In addition I planned to use a syslog server that supports TCP instead of UDP and to encrypt the traffic using stunnel. I decided to go with the cluster option and to use Polyserve Matrix Server to do the clustering.

I was planning to use syslog-ng but the production release (1.6.x) will lose messages if the syslog-ng service fails over in the cluster. See here for an explanation. There is a development release of syslog-ng 2 (1.9.x) that claims to fix this issue, however the support for sun streams seems to be incomplete or broken and I am not keen on using beta code on production servers.

So - what other options are there? Well, there is an IETF WG looking at reliable syslog. I found a couple of implimentations of this. One is the San Diego Supercomputer Center Secure Syslog (SDSCsyslog) and the other is rsyslog. SDSCsyslog doesn’t appear to have any current development being done on it and the mailing lists are almost inactive. rsyslog appears very active but from my reading of the syslog website it only supports the listener part of RFC 3195.

There is also msyslog. It supports TCP but not RFC 3195. However the last release of this was in early 2003.

For now I plan to stick with the current production release of syslog-ng but keep an eye on how rsyslog develops and look to moving to that in the future.