Posts Tagged ‘linux’

Tomcat 6 and Symbolic Links

Monday, November 2nd, 2009

Not sure if this is actually what happened, but it seems quite likely and I’m not too keen on checking again.

Basically, I use Linux at work, and I have a symbolic link that points to whichever version of a project I happen to be currently working on. Works fairly well, and means I don’t have to update a bunch of configuration information each time I check out a new branch from SVN.

However, it would seem that, if I rename the directory the symbolic link is pointing to, Tomcat 6 will see that it can no longer find the various applications I’ve deployed, and assume that it should undeploy them, thus deleting the configuration files. Damned if I know why they thought that was a good idea. Could they not have just printed out an error message and deactivated them or something?

I figure it’s a bit bloody silly, but there we go. For reference I’m using Tomcat 6.0.16. It’s also possible I’m doing something wrong, I suppose, and that I shouldn’t be placing the configuration files in the conf/Catalina/localhost/ directory, but there we go.

Unhelpful Error Messages

Wednesday, October 28th, 2009

Trying to update one of our projects to use the Ivy [1.0.0,) syntax for finding dependencies today, and discovered a few fun facts about Linx and Ivy:

  1. Despite having read/write permissions to a directory, I can’t actually change it’s permissions. Bugger. So what do I do? I copy the directory (so I’m the owner…), then delete the original directory, then rename my one back. What the hell is the point of not letting me change the permissions?!
  2. Ivy would appear to include information like the File’s owner it its hash of the file. I’m not 100% sure on that, but it would seem to be the case, as I made no changes to the ivy.xml file I was working with, just copied it around a little.
  3. IvyDE provides an absolutely useless error message: “Can’t resolve Dependency org#name;rev”. Wonderful. Why can’t you resolve it? At first, it was because the permissions on the server were set incorrectly (remember, you need execute (+x) permissisons to list a directories content…), then it turned out that the hash had failed. Now, IvyDE can’t do much about the first one, as it couldn’t even see the 1.0.1 directory. However, it could have told me that the hash had failed. Would have saved me a fair bit of time. I only found out because I ran the build on the command line… Trivial to fix once I realised the problem, but still annoying.

So yeah… That wasn’t exactly fun.