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 5.3.9.108-RC2. I've dropped the

log4j-1.2.17.jar

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

this.javaSettings

in the

Application.cfc

and I have the

loadColdFusionClassPath

property set to

true

. I can call

createObject()

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

log4j-1.2.17.jar

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:

Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:476)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 137 more

If I move Example.jar into the same folder as

log4j-1.2.17.jar

then everything works as expected. However, I'm trying to keep Example.jar in a path loaded by

this.javaSettings

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?

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.

@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.

into a folder that is loaded by the JVM via the classpath

@dswitzer Which folder specifically?

@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

JavaLoader.cfc

, 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.