http://coldfusion.com logo
#lucee
Title
# lucee
d

dswitzer

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 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:
Copy code
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?
m

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

dswitzer

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

bdw429s

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
application
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.
d

dswitzer

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
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.
2 Views