BuddyPress And Lighttpd

This is a short post that detailing how to fix a problem with the WordPress plugin BuddyPress and Lighttpd.

The problem in question:

Users that register for a site via BuddyPress are sent an email with an account activation link. Upon visiting said link, their account is supposed to be activated thereby verifying their email address. However, with the typical configuration for a WordPress site on Lighttpd (redirecting all 404s to “/index.php”), GET request parameters are not forwarded (as they shouldn’t be, really). Since BuddyPress relies on a GET parameter for the activation key (and it should not do so) this breaks the activation process.


The solution to this problem is to catch requests for activations and directly process them through the index.php routing handler. To do so, add an extra bit of configuration to your Lighttpd configuration for the site:

url.rewrite-final = (
  # Enable redirects for account activations that use a GET parameter
  "^/register/activate-account(.*)$" => "/index.php/$1"

Note that “/register/activate-account” is local to your BuddyPress configuration. It should match the URL you have configured for said action (i.e. look at an activation email to figure out what to look for).



Oracle JDBC PermGen Memory Leak Fix

Let’s talk about the Oracle JDBC drivers. If you have had the misfortune to use them, you know that there are many ways they can taint your well written application. For me, the most annoying problem is the memory leaks they leave behind when you redeploy an application without shutting down the JVM instance. Do this enough, and the drivers end up using all of the PermGen space and necessitating a restart of the JVM (undesirable when your JVM is really a web server running multiple applications). This problem has plagued me for a couple of years, and I think I have finally figured out the solution. I wrote that solution into a library I call SimpleOraclePool.

SimpleOraclePool takes care of creating a connection pool using the Oracle UCP library with the Oracle JDBC driver providing the connection. Included in the library is a ServletContextListener, named OjdbcDriverListener, that will clean up the Oracle mess when your application is unloaded (from a Servlet container, of course).

I’ll leave out the explanation of how to use it. That is all documented in the code repository’s readme and the JavaDoc included with the library. But I would like to sign this post with a message to Oracle:

........('(...´...´.... ¯~/'...') 
..........''...\.......... _.·´ 

Null Is A Vile Beast

Since my last post on Java I have been learning the Spring web framework. The Restlet detour was very enlightening, and I do prefer that framework, but everything I deal with (insofar as Java web applications) at work is based on Spring. So I want to revisit that post from a Spring based approach at some point in the future. This post, however, is about avoiding the use of null.

While working in Java I have developed a renewed love of types. After working in dynamic scripting languages for so long it is refreshing to write code where you know, as you’re writing it, the exact representation of the data. Sure, you can institute methodologies to suggest types in dynamic code; but those are easily broken for any reason. For example, this bit of JavaScript:

(function() {
  var aNumber = 0,
      foo = function(){};
  foo = function(x) {
    if (x > 0) {
      return x*x;
    } else {
      return "Invalid number";
  aNumber = foo(2);
  console.log(aNumber); // 4
  aNumber = foo(-1);
  console.log(aNumber); // "Invalid number"

Someone looking at the variable definitions would expect aNumber to always be a numeric value, but someone has come along and given it the possibility of being a string value as well. This isn’t necessarily a bug, but it can turn into one fast, and be difficult to track down. Explicitly types solves this problem before the code is ever executed — it just won’t compile.
Continue reading ‘Null Is A Vile Beast’ »

CacheViewer Continued is… Discontinued

This is a short post to notify the users of CacheView Continued that I have decided to officially stop supporting the add-on. In my last post on the subject I said that I wanted to keep the add-on going because it is invaluable to the users of Firefox that need it. That wasn’t a lie. But my schedule is completely full. I just don’t have the free time necessary to fix any of the major problems with CacheViewer Continued.

I had hoped that others would contribute to the project. That’s why I provided a public repository for the project. And that repository will live on for anyone that wants to pick the project back up. But let me warn you, developing a Firefox add-on such as this is no picnic; and it’s Mozilla’s fault.