Sameer
Sameer

Reputation: 11

NoClassDefFound Error reported for ESAPI 2.3.0.0 jar

          There was security scan run on our Project Code and Vulnerability was reported for ESAPI 2.1.0.0 jar. Hence we had to change our code to use ESAPI 2.3.0.0 with zero vulnerabilities. We changed and the code passed the security scan. However, the code is throwing error in Runtime with 

“ java.lang.NoClassDefFoundError: org.owasp.esapi.reference.DefaultValidator (initialization failure)org.owasp.esapi.reference.DefaultValidator (initialization failure)” .

The Debug log is as below :

Text:CHARACTER:java.lang.NoClassDefFoundError: org.owasp.esapi.reference.DefaultValidator (initialization failure)org.owasp.esapi.reference.DefaultValidator (initialization failure) RecoverableException File:CHARACTER:C:\ci\product-build\WMB\src\DataFlowEngine\PluginInterface\jlinklib\com_ibm_broker_plugin_CMbService.cpp Line:INTEGER:1686 Function:CHARACTER:ImbJavaExceptionUtils::throwableToNativeException Severity:INTEGER:3 Number:INTEGER:4395 Text:CHARACTER:Unhandled exception in plugin method Insert Type:INTEGER:5 Text:CHARACTER:java.lang.NoClassDefFoundError Insert Type:INTEGER:5 Text:CHARACTER:java.lang.J9VMInternals Insert Type:INTEGER:5 Text:CHARACTER:initializationAlreadyFailed Insert Type:INTEGER:5 ...

The product used here is IBM ACE v12.0.0.3 and the Java runtime version is 8.

Please help in understanding and resolving above error. We checked the forums and also some of answers written by you and tried them. But they are not seeming relevant to issue and hence posting this question over email.

Some of Trials done, but still no success : • Set Classpath variable to right jar file at runtime. • Rebuilt using the relevant Jar file. • Imported the “DefaultValidator” explicity into code.

Upvotes: 1

Views: 1211

Answers (2)

Ashishkel
Ashishkel

Reputation: 961

As mentioned in the post by Kevin, most of the time culprit is logger parameters. In our case, we were using JUL and we had missed to add esapi-java-logging.properties

Found them against the release esapi-2.5.2.0 release, in the assets section within the esapi-2.5.2.0-configuration.jar. Added it to the classpath and everything was back to normal.

Upvotes: 0

Kevin W. Wall
Kevin W. Wall

Reputation: 1462

It's hard to tell for certain because you did not provide a full exception stack trace, but generally this problem is almost always caused by misconfiguration of the ESAPI Logger and specifically the ESAPI.Logger property in the ESAPI.properties file.

I would refer you to the GitHub discussion item: https://github.com/ESAPI/esapi-java-legacy/discussions/696 or this section in the release notes: https://github.com/ESAPI/esapi-java-legacy/blob/develop/documentation/esapi4java-core-2.2.1.1-release-notes.txt#L39-L78

I partly take the blame for this because we more or less noted this in the release notes for ESAPI releases 2.2.1.0 (released on 2020-07-12 and was when this change was first made), 2.2.1.1, 2.2.2.0, 2.2.3.0, and 2.2.3.1 (released 2021-05-07), before I finally removed them in the 2.3.0.0 release. I removed them because it became evident from other posts on Stack Overflow, to our GitHub issues, and private emails to the project leaders that developers were never reading those instructions anyway. So, I felt that they were just taking up useless space. That's one reason why I moved it to the Discussion page, but we probably need to put it in an ESAPI FAQ and then get people to look at the FAQ.

Regardless, take a look at the links and see if they solve your problem. If not, follow up with your email you sent me and I will then answer you there.

HTH,

-kevin

Upvotes: 2

Related Questions