# lucee


03/15/2022, 12:41 PM
I'm hoping someone can help me with this Lucee classloader issue I'm having, related to trying to get Log4j 1.2 running in Lucee I've dropped the
into a folder that is loaded by the JVM via the classpath. I can run
createObject("java", "org.apache.log4j.Logger")
and Lucee will load the JAR. Now I have another JAR (let's call it Example.jar) being loaded via
in the
and I have the
property set to
. I can call
to load classes in Example.jar and it an instance of a class is created. However, the Example.jar is not able to see the
classes. Any attempts to initiate classes that rely on the Log4j v1 return a huge stacktrace, the root appears to be with a class loader issue:
Copy code
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger
	at java.base/
	at java.base/java.lang.ClassLoader.loadClass(
	at java.base/java.lang.ClassLoader.loadClass(
	... 137 more
If I move Example.jar into the same folder as
then everything works as expected. However, I'm trying to keep Example.jar in a path loaded by
because it's updated frequently and I want to be able to dynamically reload the JAR. Why would using Lucee's JavaLoader prevent the class from being found? Should this be working? Am I misunderstanding something?

Matt Jones

03/15/2022, 2:12 PM
what happens if you put the log4j-1.2.17.jar into the same path that this.javaSettings is pointing to? If that doesn't work, you could call createobject on the 'example.jar' and pass an array of jars as the third argument to it, including the log4j.


03/15/2022, 2:26 PM
@Matt Jones Putting it in the same path as this.javaSettings brings other class loader issues. The problem is we have a number of third party libraries that rely on Log4j 1.x and I'm trying to get them all to play nicely. I'll try adding the jar paths to the createObject() call and see what happens.


03/15/2022, 7:20 PM
into a folder that is loaded by the JVM via the classpath
@dswitzer Which folder specifically?
I've always found the load cf class path setting to be a bit vague. There are probably hundreds of class loaders floating around the JVM in some sort of unknown hierarchy and I hate how much of a black box it tends to be
Whatever class loader is added as a parent when you set that setting for the cf cp may or may not be downstream of whatever class loader loaded the folder you put your jar in.
Also, turn your
log in Lucee down to trace (I forget whether you want the server or web context, so try both I guess) and that will add a bunch of logger information for what class loaders are being used.
I doubt it will tell you about the class loaders from the servlet container, but it may help.


03/15/2022, 8:22 PM
@bdw429s, The JARs being loaded are done by setting the CLASSPATH arguments when loading Tomcat. I ultimately just migrated the parts of the code to use the old
, as it's the only reliable way I could find to resolve the issue across platforms. What's weird is if I would add the path to the Log4j jar to createObject() call, it would complain because it was finding multiple versions of the same interface.