Fiji(ImageJ) takes too long to load (on linux), together with a lengthy error message - linux

I'm using Fiji on linux (inside a virtual machine) from the command line.
Specifically I have a python script that calls many fiji macros.
Each time fiji loads it takes about a minute, making it the bottleneck of the process and slowing me considerably.
I wonder if this is normal. Could fiji perhaps be made to load more quickly?
Fiji also outputs a lengthy error message when it is called. I wonder if it is related to the lengthy time it takes to load.
The command I use to call it (for example)
//shared_directory/projects/Fiji.app/ImageJ-linux64 --headless
-macro //shared_directory/projects/retracted/fiji_scripts/patch_cropper.txt
The error message is as follows
java.awt.HeadlessException
at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:204)
at java.awt.Window.<init>(Window.java:536)
at java.awt.Frame.<init>(Frame.java:420)
at ij.plugin.frame.PlugInFrame.<init>(PlugInFrame.java:13)
at ij.plugin.frame.RoiManager.<init>(RoiManager.java:94)
at ij.macro.Interpreter.getBatchModeRoiManager(Interpreter.java:1875)
at ij.plugin.frame.RoiManager.getInstance(RoiManager.java:1795)
at ij.ImagePlus.deleteRoi(ImagePlus.java:1735)
at ij.ImagePlus.close(ImagePlus.java:391)
at ij.plugin.Commands.closeImage(Commands.java:136)
at ij.plugin.Commands.close(Commands.java:83)
at ij.plugin.Commands.run(Commands.java:29)
at ij.IJ.runPlugIn(IJ.java:187)
at ij.Executer.runCommand(Executer.java:137)
at ij.Executer.run(Executer.java:66)
at ij.IJ.run(IJ.java:297)
at ij.IJ.run(IJ.java:272)
at ij.macro.Functions.doRun(Functions.java:603)
at ij.macro.Functions.doFunction(Functions.java:96)
at ij.macro.Interpreter.doStatement(Interpreter.java:230)
at ij.macro.Interpreter.doStatements(Interpreter.java:218)
at ij.macro.Interpreter.run(Interpreter.java:115)
at ij.macro.Interpreter.run(Interpreter.java:85)
at ij.macro.Interpreter.run(Interpreter.java:96)
at ij.plugin.Macro_Runner.runMacro(Macro_Runner.java:155)
at ij.plugin.Macro_Runner.runMacroFile(Macro_Runner.java:139)
at ij.IJ.runMacroFile(IJ.java:148)
at net.imagej.legacy.IJ1Helper$4.call(IJ1Helper.java:1056)
at net.imagej.legacy.IJ1Helper$4.call(IJ1Helper.java:1052)
at net.imagej.legacy.IJ1Helper.runMacroFriendly(IJ1Helper.java:986)
at net.imagej.legacy.IJ1Helper.runMacroFile(IJ1Helper.java:1052)
at net.imagej.legacy.LegacyCommandline$Macro.handle(LegacyCommandline.java:188)
at org.scijava.console.DefaultConsoleService.processArgs(DefaultConsoleService.java:102)
at net.imagej.legacy.LegacyConsoleService.processArgs(LegacyConsoleService.java:81)
at org.scijava.AbstractGateway.launch(AbstractGateway.java:95)
at net.imagej.Main.launch(Main.java:62)
at net.imagej.Main.main(Main.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at net.imagej.launcher.ClassLauncher.launch(ClassLauncher.java:279)
at net.imagej.launcher.ClassLauncher.run(ClassLauncher.java:186)
at net.imagej.launcher.ClassLauncher.main(ClassLauncher.java:77)
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: Using incremental CMS is deprecated and will likely be removed in a future release
java.lang.IllegalArgumentException: Cannot handle app name in ij.gui.YesNoCancelDialog's public <init>(java.awt.Frame parent, java.lang.String title, java.lang.String msg)
at net.imagej.patcher.CodeHacker.replaceAppNameInCall(CodeHacker.java:446)
at net.imagej.patcher.LegacyExtensions.insertAppNameHooks(LegacyExtensions.java:419)
at net.imagej.patcher.LegacyExtensions.injectHooks(LegacyExtensions.java:291)
at net.imagej.patcher.LegacyInjector.inject(LegacyInjector.java:308)
at net.imagej.patcher.LegacyInjector.injectHooks(LegacyInjector.java:109)
at net.imagej.patcher.LegacyEnvironment.initialize(LegacyEnvironment.java:101)
at net.imagej.patcher.LegacyEnvironment.applyPatches(LegacyEnvironment.java:495)
at net.imagej.patcher.LegacyInjector.preinit(LegacyInjector.java:397)
at net.imagej.patcher.LegacyInjector.preinit(LegacyInjector.java:376)
at net.imagej.legacy.LegacyService.<clinit>(LegacyService.java:134)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at java.lang.Class.newInstance(Class.java:442)
at org.scijava.service.ServiceHelper.createServiceRecursively(ServiceHelper.java:302)
at org.scijava.service.ServiceHelper.createExactService(ServiceHelper.java:269)
at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:231)
at org.scijava.service.ServiceHelper.createServiceRecursively(ServiceHelper.java:340)
at org.scijava.service.ServiceHelper.createExactService(ServiceHelper.java:269)
at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:231)
at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:194)
at org.scijava.service.ServiceHelper.loadServices(ServiceHelper.java:166)
at org.scijava.Context.<init>(Context.java:278)
at org.scijava.Context.<init>(Context.java:234)
at org.scijava.Context.<init>(Context.java:174)
at org.scijava.Context.<init>(Context.java:160)
at net.imagej.ImageJ.<init>(ImageJ.java:77)
at net.imagej.Main.launch(Main.java:61)
at net.imagej.Main.main(Main.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at net.imagej.launcher.ClassLauncher.launch(ClassLauncher.java:279)
at net.imagej.launcher.ClassLauncher.run(ClassLauncher.java:186)
at net.imagej.launcher.ClassLauncher.main(ClassLauncher.java:77)
Caused by: javassist.CannotCompileException: No code replaced!
at net.imagej.patcher.CodeHacker$EagerExprEditor.instrument(CodeHacker.java:1280)
at net.imagej.patcher.CodeHacker.replaceAppNameInCall(CodeHacker.java:443)
... 36 more
Thanks!

I wonder if this is normal. Could fiji perhaps be made to load more quickly?
I don't think this is intended behavior. As this issue is very specific to ImageJ/Fiji, you should better raise this point on the ImageJ forum.
java.lang.IllegalArgumentException: Cannot handle app name in ij.gui.YesNoCancelDialog's public <init>(java.awt.Frame parent, java.lang.String title, java.lang.String msg)
This is likely due to ij1-patcher not handling ij.gui.YesNoCancelDialog to make it independent on the Java AWT framework (which interferes with the goal of running things headless).
You are welcome to submit a patch to the ij1-patcher project to make it deal with YesNoCancelDialog in a similar way as it currently does with GenericDialog, see these lines.
As a workaround, simply use a macro that doesn't use YesNoCancelDialog, i.e. does not run the getBoolean() macro function.
EDIT: as also noted in the ImageJ forum topic, a patch was submitted here.
Until this gets merged and released, you can work around the issue by downgrading ij.jar using Help > Update ImageJ...

Related

I'm trying to bring some depricated code .createValueBinding to the recommend code update

Here is my current code within the application Java:
SourceActiveTab activeTab = (SourceActiveTab)fc.getApplication().createValueBinding("#{sourceActiveTab}").getValue(fc);
This is what I'm trying to replace it with based on what I have found here and the web javadocs
SourceActiveTab activeTab1 = fc.getApplication().evaluateExpressionGet(fc,"#{sourceActiveTab}", SourceActiveTab.class);
This is the error I get when trying to use the fixed code. What am I missing or doing wrong?
Root cause of ServletException.
javax.faces.el.EvaluationException: Exception while invoking expression #{sourceBaseBean.selectPersonBtn}at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:156)
at javax.faces.component.UICommand.broadcast(UICommand.java:89) at javax.faces.component.UIData.broadcast(UIData.java:517)
at org.ajax4jsf.framework.ajax.AjaxViewRoot.processEvents(AjaxViewRoot.java:180) at org.ajax4jsf.framework.ajax.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:158) Truncated. see log file for complete stacktrace
Caused By: java.lang.NoSuchMethodError: javax.faces.application.Application.evaluateExpressionGet(Ljavax/faces/context/FacesContext;Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object; at lean.source.beans.SourceBaseBean.selectPersonBtn(SourceBaseBean.java:246)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)

Spark 2.4.1 can not read Avro file from HDFS

I have a simple code block to write then read dataframe as Avro format. As the Avro lib already built in Spark 2.4.x,
The Avro files writing went succeed and files are generated in HDFS. However AbstractMethodError exception is thrown when I read the files. Can anyone share me some light?
I used the Spark internal library by adding the package org.apache.spark:spark-avro_2.11:2.4.1 in my Zeppelin nodebook Spark interpreter.
My simple code block:
%pyspark
test_rows = [ Row(file_name = "test-guangzhou1", topic='camera1', timestamp=1, msg="Test1"), Row(file_name = "test-guangzhou1", topic='camera1', timestamp=2, msg="Test2"), Row(file_name = "test-guangzhou3", topic='camera3', timestamp=3, msg="Test3"), Row(file_name = "test-guangzhou1", topic='camera1', timestamp=4, msg="Test4") ]
test_df = spark.createDataFrame(test_rows)
test_df.write.format("avro")
.mode('overwrite').save("hdfs:///tmp/bag_parser279181359_3")
loaded_df = spark.read.format("avro").load('hdfs:///tmp/bag_parser279181359_3')
loaded_df.show()
The error message I saw:
Py4JJavaError: An error occurred while calling o701.collectToPython.
: java.lang.AbstractMethodError
at org.apache.spark.sql.execution.FileSourceScanExec.inputRDD$lzycompute(DataSourceScanExec.scala:337)
at org.apache.spark.sql.execution.FileSourceScanExec.inputRDD(DataSourceScanExec.scala:331)
at org.apache.spark.sql.execution.FileSourceScanExec.inputRDDs(DataSourceScanExec.scala:357)
at org.apache.spark.sql.execution.WholeStageCodegenExec.doExecute(WholeStageCodegenExec.scala:627)
at org.apache.spark.sql.execution.SparkPlan$$anonfun$execute$1.apply(SparkPlan.scala:137)
at org.apache.spark.sql.execution.SparkPlan$$anonfun$execute$1.apply(SparkPlan.scala:133)
at org.apache.spark.sql.execution.SparkPlan$$anonfun$executeQuery$1.apply(SparkPlan.scala:161)
at org.apache.spark.rdd.RDDOperationScope$.withScope(RDDOperationScope.scala:151)
at org.apache.spark.sql.execution.SparkPlan.executeQuery(SparkPlan.scala:158)
at org.apache.spark.sql.execution.SparkPlan.execute(SparkPlan.scala:133)
at org.apache.spark.sql.execution.SparkPlan.getByteArrayRdd(SparkPlan.scala:289)
at org.apache.spark.sql.execution.SparkPlan.executeTake(SparkPlan.scala:381)
at org.apache.spark.sql.execution.CollectLimitExec.executeCollect(limit.scala:38)
at org.apache.spark.sql.Dataset$$anonfun$collectToPython$1.apply(Dataset.scala:3259)
at org.apache.spark.sql.Dataset$$anonfun$collectToPython$1.apply(Dataset.scala:3256)
at org.apache.spark.sql.Dataset$$anonfun$53.apply(Dataset.scala:3373)
at org.apache.spark.sql.execution.SQLExecution$$anonfun$withNewExecutionId$1.apply(SQLExecution.scala:79)
at org.apache.spark.sql.execution.SQLExecution$.withSQLConfPropagated(SQLExecution.scala:144)
at org.apache.spark.sql.execution.SQLExecution$.withNewExecutionId(SQLExecution.scala:74)
at org.apache.spark.sql.Dataset.withAction(Dataset.scala:3367)
at org.apache.spark.sql.Dataset.collectToPython(Dataset.scala:3256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at py4j.reflection.MethodInvoker.invoke(MethodInvoker.java:244)
at py4j.reflection.ReflectionEngine.invoke(ReflectionEngine.java:357)
at py4j.Gateway.invoke(Gateway.java:282)
at py4j.commands.AbstractCommand.invokeMethod(AbstractCommand.java:132)
at py4j.commands.CallCommand.execute(CallCommand.java:79)
at py4j.GatewayConnection.run(GatewayConnection.java:238)
at java.lang.Thread.run(Thread.java:748)
(<class 'py4j.protocol.Py4JJavaError'>, Py4JJavaError(u'An error occurred while calling o701.collectToPython.\n', JavaObject id=o702), <traceback object at 0x7fc031b5c878>)
AbstractMethodError :
Thrown when an application tries to call an abstract method. Normally, this error is caught by the compiler; this error can only occur at run time if the definition of some class has incompatibly changed since the currently executing method was last compiled.
AFAIK you have to investigate on what versions you have used to compile and run.
There is a similar but different question being asked here that pertains to using spark-avro on emr-5.28.0. It's not the same cause as what's being discussed here in this question (since this question was asked long before emr-5.28.0 was available), but it's similar enough that I figured I'd link to my answer for that one in case anybody stumbles upon this question due to the similar looking stacktrace and similar sounding question.

tomcat classloader performance issue

Our benchmarking uncovered a bootleneck in Apache Tomcat 7.0.59. When the server reaches its performance limit, most of its threads are locked by ClassLoader.
Stack traces of blocked threads looks like this example:
"http-bio-4504-exec-500" Id=2335 BLOCKED on java.util.jar.JarFile#464f9f8 owned by "[1432628598653] POST /services/signin HTTP/1.0" Id=1990
at java.util.zip.ZipFile.getEntry(ZipFile.java:304)
- blocked on java.util.jar.JarFile#464f9f8
at java.util.jar.JarFile.getEntry(JarFile.java:226)
at java.util.jar.JarFile.getJarEntry(JarFile.java:209)
at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:840)
at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:818)
at sun.misc.URLClassPath$1.next(URLClassPath.java:226)
at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:236)
at java.net.URLClassLoader$3$1.run(URLClassLoader.java:583)
at java.net.URLClassLoader$3$1.run(URLClassLoader.java:581)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader$3.next(URLClassLoader.java:580)
at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:605)
at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45)
at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54)
at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45)
at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54)
at com.sun.xml.ws.util.ServiceFinder$LazyIterator.hasNext(ServiceFinder.java:443)
at com.sun.xml.ws.util.ServiceFinder$CompositeIterator.hasNext(ServiceFinder.java:390)
at com.sun.xml.ws.api.message.saaj.SAAJFactory.getMessageFactory(SAAJFactory.java:96)
at com.sun.xml.ws.api.SOAPVersion.getMessageFactory(SOAPVersion.java:221)
at com.sun.xml.ws.api.message.saaj.SAAJFactory.readAsSOAPMessage(SAAJFactory.java:275)
at com.sun.xml.ws.api.message.saaj.SAAJFactory.readAsSAAJ(SAAJFactory.java:205)
at com.sun.xml.ws.api.message.saaj.SAAJFactory.read(SAAJFactory.java:194)
at com.sun.xml.ws.message.AbstractMessageImpl.toSAAJ(AbstractMessageImpl.java:199)
at com.sun.xml.ws.api.message.MessageWrapper.readAsSOAPMessage(MessageWrapper.java:160)
at com.sun.xml.ws.handler.SOAPMessageContextImpl.getMessage(SOAPMessageContextImpl.java:86)
and the blocker thread is running at the same place
"[1432628598653] POST /services/signin HTTP/1.0" Id=1990 RUNNABLE
at java.util.zip.ZipFile.getEntry(ZipFile.java:304)
- locked java.util.jar.JarFile#464f9f8
at java.util.jar.JarFile.getEntry(JarFile.java:226)
at java.util.jar.JarFile.getJarEntry(JarFile.java:209)
at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:840)
at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:818)
at sun.misc.URLClassPath$1.next(URLClassPath.java:226)
at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:236)
at java.net.URLClassLoader$3$1.run(URLClassLoader.java:583)
at java.net.URLClassLoader$3$1.run(URLClassLoader.java:581)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader$3.next(URLClassLoader.java:580)
at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:605)
at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45)
at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54)
at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45)
at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54)
at com.sun.xml.ws.util.ServiceFinder$LazyIterator.hasNext(ServiceFinder.java:443)
at com.sun.xml.ws.util.ServiceFinder$CompositeIterator.hasNext(ServiceFinder.java:390)
at com.sun.xml.ws.api.message.saaj.SAAJFactory.read(SAAJFactory.java:190)
at com.sun.xml.ws.message.AbstractMessageImpl.toSAAJ(AbstractMessageImpl.java:199)
at com.sun.xml.ws.api.message.MessageWrapper.readAsSOAPMessage(MessageWrapper.java:160)
at com.sun.xml.ws.handler.SOAPMessageContextImpl.getMessage(SOAPMessageContextImpl.java:86)
Do our applications do something in a wrong way? Is there a workaround to avoid blocking in classloaders?
The problem was fixed completely with the following hack:
I added -Djaxp.debug=true to JVM args.
Then I found in logs all classes that JAX-WS was looking for.
I added system property for every mentioned class, and it made ServiceFinder to omit searching for service.properties files in classpath.
My final JVM args looked like:
-Djavax.xml.soap.MetaFactory=com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl
-Djavax.xml.datatype.DatatypeFactory=com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl
-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl
-Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl
-Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory
-Djavax.xml.stream.XMLOutputFactory=com.ctc.wstx.stax.WstxOutputFactory
-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl

Getting StackTraceElement in groovy application

I have a piece of code that prints the current java file for logging purposes.
final StackTraceElement stackTraceElement = new Throwable().fillInStackTrace().getStackTrace()[2];
final String parentClassName = stackTraceElement.getFileName().replaceAll(".java", "");
final int lineNumber = stackTraceElement.getLineNumber();
I wrote something in groovy that uses the above code to print logs, it works, most of the time, however after couple of runs I'm starting to get NPE
java.lang.NullPointerException
at com.bla.general.util.log.LogUtils.generateLogMessage(LogUtils.java:140)
at com.bla.general.util.log.LogUtils.info(LogUtils.java:67)
at sun.reflect.GeneratedMethodAccessor831.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:324)
at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.invoke(StaticMetaMethodSite.java:43)
at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.call(StaticMetaMethodSite.java:88)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at com.bla.AppVersionServiceImpl.getAppVersion(AppVersionServiceImpl.groovy:47)
When the following line is the originator:
LogUtils.info("Trying to get details for device hash ${deviceHash}");
I'm using tomcat and java 1.7 as my stack. After restarting Tomcat things get back to normal.
It's my first endeavor to the dynamic world of JVM. I'll appreciate if you can enlighten me

Errors in integrating ESAPI suite with MyEclipse j2ee project

Hi, I am trying to integrate of checkmarx plug in with my project in
myEclipse. I copied the jars (i.e. antisamy-1.4.3.jar &
esapi-2.1.0.jar ) my current jars directory and included in the
project libraries of myeclipse. And copied the property files into
my source directory of project i.e. ESAPI.properties &
validation.properties (prop files) where all my project property
files exists. Below is the screen shot Now I am trying to test if my
integration of ESapi successful. For that I have a create a test
java class(which is provided in the document i.e.
esapi4java-core-2.0-install-guide.pdf ) in my source folder, no
compilation errors found. But when I am running it is giving error ,
so what am I making mistake could you please help me.
Exception log :
SecurityConfiguration for ESAPI.printProperties not found in
ESAPI.properties. Using default: false Exception in thread "main"
org.owasp.esapi.errors.ConfigurationException:
java.lang.reflect.InvocationTargetException AccessController class
(org.owasp.esapi.reference.DefaultAccessController) CTOR threw
exception. at
org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:129) at
org.owasp.esapi.ESAPI.accessController(ESAPI.java:85) at
com.steelwedge.util.checkmarx.EsapiTest.main(EsapiTest.java:14)
Caused by: java.lang.reflect.InvocationTargetException at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597) at
org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:86) ... 2 more
Caused by: java.lang.NoClassDefFoundError:
org/apache/commons/configuration/ConfigurationException at
org.owasp.esapi.reference.DefaultAccessController.(DefaultAccessController.java:32)
at
org.owasp.esapi.reference.DefaultAccessController.getInstance(DefaultAccessController.java:22)
... 7 more Caused by: java.lang.ClassNotFoundException:
org.apache.commons.configuration.ConfigurationException at
java.net.URLClassLoader$1.run(URLClassLoader.java:202) at
java.security.AccessController.doPrivileged(Native Method) at
java.net.URLClassLoader.findClass(URLClassLoader.java:190) at
java.lang.ClassLoader.loadClass(ClassLoader.java:307) at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at
java.lang.ClassLoader.loadClass(ClassLoader.java:248) ... 9 more
Thank you. ~Shyam
I'm not familiar with ESAPI but note that the error includes "Caused by: java.lang.ClassNotFoundException: org.apache.commons.configuration.ConfigurationException"
The class, org.apache.commons.configuration.ConfigurationException, is in the commons-configuration.jar, so you will need that jar in your classpath also (and maybe others).
Note that for web applications, you may also need to add jars to the Deployment Assembly (right click the project, select Properties and then go to the MyEclipse/Deployment Assembly page - you can add jars from the classpath or individuals jars) as this controls what gets deployed to the server.

Resources