glftpd trouble after upgrading to Ubuntu 10.04

Today I upgraded three computers running Ubuntu 8.04 LTS to the latest version 10.04. On one of the computers I had glftpd running and it did not work anymore after the upgrade. When I checked for the open ports

netstat -anp --tcp --udp | grep LISTEN

the port glftpd was previously running on, was not in the list anymore and also ps aux | grep glftpd did not show the process. The error "service/protocol combination not in /etc/services: glftpd/tcp" could be seen when restarting xinetd

sudo /etc/init.d/xinetd restart

while tailing syslog

tail -100f /var/log/syslog

All that was missing was a entry in /etc/services at the end.

# Local services
glftpd          10087/tcp                       # glftpd

First I thought the 10.04 upgrade process was flawed but then I remembered that Ubuntu actually asked me to keep or overwrite some files which I had modified in 8.04. I almost always decided to overwrite the files, except for some local Apache modifications. Apparently /etc/services was one of the files that had changed.

Dependencies clashing with Maven Overlays

Last year I wrote about a Maven feature which I had discovered back then, that made it possible to "merge" two web-applications using overlays. Unfortunately I discovered a very annoying problem with overlays today. In my current project I am using the decode method in the Base64 class in commons-codec. The method was added in commons-codec 1.4. One of the overlay WAR files comes with an older version of commons-codec. What Maven does is that it just throws the dependencies from the overlay project together with your referring project. Make sure you have a look in the lib folder after running mvn package. When I looked into my lib directory in my WEB-INF folder, I realized that I had commons-codec-1.4.jar as well as commons-codec-1.3.jar (the one coming with the overlay) in there. When the web-application loads, version 1.3 is picked up causing a Runtime Exception because the decode method was missing.

This is pretty serious I think. First of all, I did not realize that the 1.3 dependency slipped in with the overlays. I ran mvn dependency:tree -Dverbose -Dincludes=commons-codec to see what happened but it did not show me any library using commons-codec 1.3. It took a while until I realized what the problem was and that the Maven dependency plugin would not help me here. I went into my local repository and ran a find . -name '*.pom' -exec grep -nH 'commons-codec' {} \; to be able to spot projects using commons-codec. I would like to see a Maven plugin where it can find you libraries using a certain version of a dependency. Anyway, I was lucky. The overlay projects could be upgraded to use codec 1.4 instead and the dependency clash went away.

Unfortunately one of the WAR overlays uses dom4j-1.6.1.jar which has a dependency to xml-apis-1.0.b2.jar. In the project where I refer to the overlay it depends on xms-apis-1.3.04.jar - so here I am having two jar's of the same type in the classpath and no easy way to fix this.