I realised something today, I've been telling something about the JavaLoader that isn't true.
By default, JavaLoader loads the ColdFusion class path as its parent when loading in custom Java libraries.
This means that if JavaLoader can't find a class that you are loading through it via the Jars that you have loaded, it will look to what ColdFusion has loaded to see if it can find it there.
I had always assumed that if you loaded something, say for example, the newer version of log4j with JavaLoader, for the Jars loaded with JavaLoader, they would see the newer version, rather than the older version of log4j with ColdFusion.
This is actually, completely and utterly false. I apologise for all the frustration I probably incurred on people for making this statement.
Reading the Java docs it explicitly says : 'When requested to find a class or resource, a ClassLoader instance will delegate the search for the class or resource to its parent class loader before attempting to find the class or resource itself.'
So this means that when looking for log4j – the one in ColdFusion actually takes precedence!
This makes sense in the Java world, as it allows for less confusion from the Java engine to be able to resolve classes – but from a ColdFusion perspective it makes life very difficult as we don't have the ability to modify what is loaded at application startup as we would if we had written a Java application from scratch.
A workaround for this is to pass Java null into the JavaLoader as a second variable like so:
loader = createObject("component", "JavaLoader").init(paths, JavaCast("null", ""));
This will create a JavaLoader that is not set with ColdFusion as the parent.
I am currently working on JavaLoader 0.3, that will make the precedence on the loaded classes that will solve this problem all up, as well as some parameters to avoid loading the ColdFusion classpath altogether, but I thought I would give people a heads up now to avoid frustration down the road.