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.
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.
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.
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 -
More info about the magic _POSIX2_VERSION flag; note it isn’t limited to the tail command.
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.
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!