Just updated (via the admin) a local dev 5.3.8.206 Tomcat install to 5.3.9.133 and immediately got an error with this simple line of code:
dump( EncodeForHtml( "test" ) )
java.lang.reflect.InvocationTargetException Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception.
Stack trace
lucee.runtime.exp.NativeException: java.lang.reflect.InvocationTargetException Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception.
at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:129)
at org.owasp.esapi.ESAPI.encoder(ESAPI.java:99)
at org.lucee.extension.esapi.functions.ESAPIEncode.encode(ESAPIEncode.java:63)
at org.lucee.extension.esapi.functions.ESAPIEncode.encode(ESAPIEncode.java:56)
at org.lucee.extension.esapi.functions.EncodeForHTML.call(EncodeForHTML.java:29)
at org.lucee.extension.esapi.functions.EncodeForHTML.call(EncodeForHTML.java:33)
at org.lucee.extension.esapi.functions.EncodeForHTML.invoke(EncodeForHTML.java:37)
at lucee.runtime.functions.FunctionHandlerPool.invoke(FunctionHandlerPool.java:40)
at index_cfm$cf.call(/index.cfm:2)
...[snip]
Caused by: org.owasp.esapi.errors.ConfigurationException: java.lang.reflect.InvocationTargetException Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception.
... 43 more
Caused by: java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:86)
... 42 more
Caused by: org.owasp.esapi.errors.ConfigurationException: java.lang.ClassNotFoundException: org.lucee.extension.esapi.log.LogFactoryImpl not found by org.lucee.esapi [62] LogFactory class (org.lucee.extension.esapi.log.LogFactoryImpl) must be in class path.
at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:108)
at org.owasp.esapi.ESAPI.logFactory(ESAPI.java:137)
at org.owasp.esapi.ESAPI.getLogger(ESAPI.java:154)
at org.owasp.esapi.reference.DefaultEncoder.<init>(DefaultEncoder.java:75)
at org.owasp.esapi.reference.DefaultEncoder.getInstance(DefaultEncoder.java:59)
... 47 more
Caused by: java.lang.ClassNotFoundException: org.lucee.extension.esapi.log.LogFactoryImpl not found by org.lucee.esapi [62]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1597)
at org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:315)
at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:74)
... 51 more
This trace seems to be identical to the one reported by Dave Stanley a few days ago in the comments of this ticket:
But unlike him downgrading the ESAPI extension from version 2.2.4.5 to the previous 2.2.0.1 version fixed it for me.
However, spinning up a command box server running 5.3.9.133 and ESAPI 2.2.4.5 the code runs just fine! So this must be some kind of edge case. Anyone else seen it?
We encounter the same issue. No matter what string we provide, encodeForHTML() causes the same error as mentioned above. We’ll try downgrading ESAPI now.
What’s interesting is I received the COTR error a few times recently, but on 5.3.8 and updating to the 5.3.0 snapshot was actually the fix. I don’t really know what the error means though and when I posted it in the #Lucee channel on CFML Slack a couple times, no one really had heard of it so I assumed it was just me.
I’m not sure what constellation of upgrade/downgrade is causing this, but i will further investigate.
Problem is the file /lucee/temp/properties/ESAPI.properties that contains this line:
We had to set this line so, the ESAPI library is not using log4j directly anymore, instead it is using our own factory that point to the Lucee core log framework (what is log4j2).
Problem for sure is, when you downgrade to an older version and you have this setting, you get this bug, because the older implementation simply does not have this class.
we did fix this by changing the location of that properties file to /Lucee/temp/esapi224/ESAPI.properties, so every version has it’s own properties file and they no longer conflict.
As a workariund, simply delete the file /lucee/temp/properties/ESAPI.properties
Thanks, Micha, but I that didn’t work for me. I also tried deleting the entire contents of the temp/ directory but the error was still thrown. With each change I restarted Tomcat/Lucee before testing again.
Once again, downgrading to ESAPI 2.2.0.1 did fix it.
That would make sense if I had upgraded to ESAPI 2.2.4.5 and then (for some reason) downgraded again to 2.2.0.1.
But I didn’t. I’ve been testing with only the latest ESAPI extension installed. Surely that does have the org.lucee.extension.esapi.log.LogFactoryImpl class and the reference in the new esapi224/ESAPI.properties file should work?
This is after upgrading ESAPI to 2.2.4.5 and double-checking that the previous version bundles have gone from by bundles directory. In which case why is that older version still present and active? Where can it be coming from? Have searched my entire Tomcat/Lucee install folder but can’t locate it.
I should have triple-checked my tomcat\lucee-server\bundles folder. Found the offending file which was named org-lucee-esapi-2-1-0-1.jar with hyphens instead of dots. Deleted. Restarted. All working again
@micstriit So is this just a clean-up problem when the extension is upgraded?
I wanted to add my two cents to this discussion because I had the same issue. I had a 5.3.3 installation that I had upgraded with the ESAPI 2.2.0.0 extension installed and upgraded the extension to 2.2.4.7 and the old setting for the ESAPI.logger was still in place. Until I had discovered that I needed to update that with
org.lucee.extension.esapi.log.LogFactoryImpl
My site would crash with the similar error where the class it couldn’t find was
org.owasp.esapi.reference.Log4JLogFactory
Once it was updated and restarted then my site worked as expected.
hyphens means it was dynamically downloaded via the update provider, dots means it was installed.
there was bug in Lucee, which was discovered and fixed in 5.3.10.79 which hardwired the extension version in generated bytecode, triggering a dynamic download of the older bundle
after a lot of trial and error n debugging, I figured it out, it should be now solved [LDEV-4187] - Lucee
If anyone finds this in the future and the solutions in this thread didn’t work for them, I had the opposite issue to this post. I was upgrading from an older version and my ESAPI.properties still had the reference to the log4j class, so I replaced it with org.lucee.extension.esapi.log.LogFactoryImpl. Works like a charm.
