• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Invocation Target Exception in Java

C

CefiroZ

Limp Gawd
Joined
Jan 17, 2004
Messages
218
I'm trying to run Centric (now Concursive) CRM on a linux box. I have it up and running except a couple of pages do not work, apparently because they use charts. When looking at tomcat's catalina.out I get errors like the following whenever the bad pages are clicked:

Code: 
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at com.darkhorseventures.framework.servlets.ControllerServlet.service(Unknown Source)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
        at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
        at java.lang.Thread.run(Thread.java:636)
Caused by: java.lang.IncompatibleClassChangeError: Found class com.sun.image.codec.jpeg.JPEGImageEncoder, but interface was expected
        at org.jfree.chart.encoders.SunJPEGEncoderAdapter.encode(SunJPEGEncoderAdapter.java:136)
        at org.jfree.chart.encoders.EncoderUtil.writeBufferedImage(EncoderUtil.java:153)
        at org.jfree.chart.ChartUtilities.writeChartAsJPEG(ChartUtilities.java:473)
        at org.jfree.chart.ChartUtilities.saveChartAsJPEG(ChartUtilities.java:582)
        at org.aspcfs.modules.contacts.actions.Sales.executeCommandDashboard(Unknown Source)
        ... 20 more
Exception. MESSAGE = null

The actual exception is hard to pin down thanks to the super generic last line there. Note that the package darkhorseventures is part of the Centric CRM stuff. It appears to be an issue with JFreeChart but I'm not well versed in the errors presented. Can anyone explain the problem and possibly propose a solution?
 
Okay I did find this page that discusses the particular error. Is the only way to fix the problem to install Sun's JDK? I am using Red Hat Enterprise Linux 4 to host this and Sun's packages aren't included in the RHN repos. The installers that you get from Sun install in a nonstandard location and don't interface well with the alternatives program. Anyone know an easy fix here?
 
CefiroZ said:
Okay I did find this page that discusses the particular error. Is the only way to fix the problem to install Sun's JDK? I am using Red Hat Enterprise Linux 4 to host this and Sun's packages aren't included in the RHN repos. The installers that you get from Sun install in a nonstandard location and don't interface well with the alternatives program. Anyone know an easy fix here?
Click to expand...

There is no standard location for installing Java, and it seems every distro does it differently.

I would just grab the latest JRE for your platform install it somewhere (/usr/local/java) and then link /usr/local/java/bin/java into /usr/bin/. Problem solved.

As for JFreeChart, looking at the stack trace it appears they referenced an internal SUN API (which SUN javac raises a warning not to do), so yes you will need SUN's JDK or JRE.
 
Just wanted to give the update that installing Sun's Java does *not* fix this error, at least not for my install.

I basically did the same thing as found here, which has you download the JDK , extract to a directory, and update alternatives to point at the new java binary. To get Centric and Tomcat to not complain I also had to make a link in one place. The link is in /usr/lib/jvm-exports and I chose to have java-1.6.0-sun to point to java-1.6.0-openjdk. The directories in jvm-exports contain a series of jar files. Also, while there is a java-1.6.0-sun-1.6.0.11 (I believe leftover from the rpm version of Sun's installer that I tried at an earlier time), if the java-1.6.0-sun link points to it instead of the openjdk folder I still get the error.

JAVA_HOME is pointing to the installed directory, alternatives points to the proper place also, and running 'java -version' confirms that Sun's java is the one that is executed. Not sure what else would still be looking at OpenJDK instead of Sun that is causing the error to remain.
 
CefiroZ said:
JAVA_HOME is pointing to the installed directory, alternatives points to the proper place also, and running 'java -version' confirms that Sun's java is the one that is executed. Not sure what else would still be looking at OpenJDK instead of Sun that is causing the error to remain.
Click to expand...

How are you starting tomcat?
 
Looking at the init.d script provided by the tomcat5.5 package here http://packages.ubuntu.com/jaunty/tomcat5.5

It looks like it searches for a jdk to use and sets that to $JAVA_HOME in this order unless you define it $JAVA_HOME in /etc/default/tomcat5.5

/usr/lib/jvm/default-java /usr/lib/jvm/java-6-openjdk /usr/lib/jvm/java-6-cacao /usr/lib/jvm/java-6-sun /usr/lib/jvm/java-1.5.0-sun /usr/lib/jvm/java-gcj


So you can either set $JAVA_HOME in /etc/default/tomcat5.5, edit the script by hand, or link /usr/lib/jvm/default-java to a java install of your choice. Take your pick
 
Most likely Tomcat is still using the wrong Java executable,a s others have said. Since you're using redhat, try running the alternatives command:

as root:
alternatives --config java

and see what java executable is being used. If you see it using GCJ or openJDK, that's probably your issue. Use alternatives to select the Sun java executable. If it's not available, use alternatives --install to let alternatives know about it.
 
I completely missed the fact you were using Red Hat, so I assumed Ubuntu.

The same concept applies though. You should check the service script.
 
Thanks for the suggestions all, but it still isn't working. I downloaded the .bin file from Sun's site (not the rpm.bin), extracted, and moved the folder into /usr/lib/jvm.

alternatives --config java -> I have chosen the Sun version (after adding it)
java -version -> shows Sun as being the one found, for both root and tomcat users
JAVA_HOME set to the appropriate Sun folder for users root and tomcat in bashrc, echo verified this
JAVA_HOME set to the same folder in /etc/tomcat5/tomcat5.conf
 
CefiroZ said:
Isn't that what JAVA_HOME specifies? I don't recall anything else pertaining to Java in the tomcat file other than the JAVA_OPTS for things like memory size and such.
Click to expand...

The tomcat start script might be choosing its own JAVA_HOME. Can you please post the start script? (Remember to use code tags).
 
Sorry I was trying to make it clear that JAVA_HOME was set in the startup script to point at the proper Sun java location. Unfortunately I cannot post the script because the box got wiped out and I started again from the beginning with a fresh install of CentOS 5. The problem may have been a result of several attempts to install Java in several different ways on the Red Hat box, or may have been something goofy with Red Hat. In any case I got everything running smoothly in the CentOS box when doing the Java install from the beginning based on method two found here
 
You must log in or register to reply here.
Back
Top