One of the more frustrating things to diagnose when supporting our products are classpath issues. You know the ones. The guy has copied an upgrade of Confluence over an older version and has multiple versions of each jar in the classpath; some admin has copied random jars from random places into other random places; someone thought it was a smart idea to build the application using their favourite, obscure software building environment. The list could go on. Finding out where a particular web container is sourcing its jars from can be a nightmare in itself. Help is now here.

I’ve just checked some code into Confluence 2.3 which will give users and support staff the ability to painlessly view the current system classpath in a running version of Confluence by visiting /admin/classpath.action.

Hopefully this will significantly reduce the turnaround time in diagnosing these types of problems in Confluence 2.3 and beyond.


For the curious, this is possible because most Java runtime enviroments use a URLClassLoader as the system classloader, allowing us to iterate over the set of URLs that are scanned for classes.

* This method will return an array of URLs used by the system
* classloader. If the system classloader is not an instance
* of {@link URLClassLoader}, this method will return null
* @return Array of URLs in classpath lookup order or null if
* the system classloader does not support classpath discovery
public static URL[] getSystemClasspath()
ClassLoader base = ClassLoader.getSystemClassLoader();
if (base instanceof URLClassLoader)
return ((URLClassLoader) base).getURLs();
return null;

Taming wild classpaths