Your Daily Fix

Tuesday, August 12th - Make tables appear in PDF with Apache FOP

Tue, 12 Aug 2008 21:43:56 -0500

Apache FOP is sophisticated rendering package for translating from a valid document specified in the XSL-FO formatting language into a variety of output formats such as PDF, PNG, and RTF.

I ran into a weird issue where I was converting HTML into XSL-FO using a well-known stylesheet for this purpose, and then converting from the XSL-FO into PDF. For some reason, HTML tables were appearing in RTF output but not PDF output. The source of the problem was the use of the fo:table-with-caption construct being generated by the HTML to XSL-FO transform, which is not supported by FOP. I altered the transform to just use the fo:table construct without the wrapped fo:table-with-caption and the table shows up as expected.

Wednesday July 11th - Upgrade the MySQL JDBC drivers

Wed, 11 Jun 2008 14:25:32 -0500

On two separate occasions, I’ve downloaded open source war-based Java applications that install and run perfectly well in a recent Tomcat, only to discover that I am unable to log in with the default administrator credentials. From a bit of debugging, it appears that the hash function for generating the password hash does not generate something that matches the database column. I don’t really know why this is, but I do know how to fix it:

In both cases, the applications shipped with MySQL JDBC drivers 3.x. Removing the shipped version in the WEB-INF/lib folder and replacing it with the 5.x version immediately fixed the problem. So if you find yourself having trouble logging into a Java-based web application, check the MySQL drivers and replace as necessary.

Daily Fix - Tuesday, April 15 2008

Tue, 15 Apr 2008 14:30:36 -0500

I needed to check in some subversion code that lived on someone else’s machine, and normally that code is managed via Eclipse/Subclipse. However, I couldn’t launch Eclipse “as them”, even though I could access the code via the command line. The problem was that the code is checked out via svn+ssh, and I didn’t know the user’s ssh password, so I needed it to be checked in as me. There is no obvious way to do this via svn command. Turns out you need to set an environment variable (this appears to be a recurring theme thus far in this series). Set SVN_SSH to:

ssh -l

As in:

SVN_SSH=”ssh -l someuser”; export SVN_SSH

where someuser is a user for whom you know the password/have credentials. It should then act as though someuser is doing the committing.

Daily Fix - Saturday April 12th 2008

Sat, 12 Apr 2008 17:08:00 -0500

My Toshiba laptop started suddenly refusing to suspend and resume on Fedora Core 8 after I did some upgrades. It turns out that, at least based on my experimentation, the kvm and kvm_intel (for doing virtualization on Linux) modules are the culprit. Luckily, the fix for this is easy. If it doesn’t already exist, create the file:

/etc/pm/config.d/unload_modules

Add a line to that file:

SUSPEND_MODULES=”kvm_intel kvm”

That fixed the problem on my system.

Standards conformance - GNU Coreutils

Fri, 11 Apr 2008 14:37:34 -0500

Standards conformance - GNU Coreutils:

More info about the magic _POSIX2_VERSION flag; note it isn’t limited to the tail command.

Daily Fix - Friday, April 11th 2008

Fri, 11 Apr 2008 11:25:00 -0500

I often need to grab older versions of libraries and applications, and I’ve encountered a recurring problem when I pull down an application packed as a self-extracting archive for Linux. These usually end in .bin and force you to accept some sort of agreement, then unpack themselves. I’ve seen this with older version of the Sun Java release (i.e. 1.4 and before) on Linux, but it occurs elsewhere. The problem is that the application script calls tail using an older syntax like this:

tail +305 …

which means print the file (or bytes or whatever) starting at line 305. That particular syntax isn’t supported anymore due to a standardization of the way arguments are passed in POSIX systems. See:

http://www.cygwin.com/ml/cygwin/2005-03/msg01112.html

So when the archive tries to unpack, it freaks out and you see some error about unsupported syntax for tail and you get nothing on the output. You can fix this by setting a magic environment variable called _POSIX2_VERSION. By default it is set to 200112, but if you change it to 199209, tail will be accept the old argument style. So to unpack those old archives, do:

> _POSIX2_VERSION=199209; export _POSIX2_VERSION
> ./the_previously_misbehaving_archive.bin

Since you only set the environment for the shell, quitting and reopening a new shell will clear this value. Also be careful that if you are unpacking the archive using sudo, this trick will fail since the environment variable doesn’t get passed through.

Get your daily fix

Fri, 11 Apr 2008 11:12:25 -0500

I spend most of my day fixing things. I often come across or develop workarounds or fixes for niche problems, by which I mean problems that the average user is unlikely to have, but which developers working with a particular system might be very likely to encounter. Since I don’t really have time to blog regularly, I thought that creating a tumblelog to capture these, once a day or every other day, would be worth a shot. If you find a fix helpful, or have a better solution to one of my problems, let me know!