Did you guys manage to figure out the solution to that last error - the 500 ROOT CAUSE:

java.lang.NoClassDefFoundError ??

I had the same problems going forward and now have landed at this one as well. Any ideas?
Thanks-

I had the sysadmin put the jar files directly into the coldfusionRoot/WEB-INF/lib directory. I had initially received the same original error the OP had, and it went away after copying all 4 of the required JAR files into the coldfusionRoot/WEB-INF/lib directory. Now, I get this 500 error.

The API files and documentation can be found in the matrix here:

http://www.cybersource.com/support_center/implementation/downloads/sim ple_order/matrix.htmlUnfortunately,

there is very scant information pertaining to plugging Coldfusion into the

Java version, its kind of tagged onto it.

Full error detail:

500

ROOT CAUSE:

java.lang.NoClassDefFoundError: Could not initialize class

com.cybersource.ws.client.Signature

     at com.cybersource.ws.client.Client.soapWrapAndSign(Client.java:200)

     at com.cybersource.ws.client.Client.runTransaction(Client.java:103)

     at com.cybersource.ws.client.Client.runTransaction(Client.java:53)

     at CyberSource.runTransaction(CyberSource.java:32)

     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39)

     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25)

     at java.lang.reflect.Method.invoke(Method.java:597)

     at coldfusion.runtime.java.JavaProxy.invoke(JavaProxy.java:87)

     at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:2272)

     at cfcheckout22ecfm2002022632.runPage(/usr/local/apache2/htdocs/sfs/cybe rsource_api_test/checkout2.cfm:42)

     at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:196)

     at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:370)

     at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65)

     at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:279 )

     at coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40)

     at coldfusion.filter.PathFilter.invoke(PathFilter.java:86)

     at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:70)

     at coldfusion.filter.BrowserDebugFilter.invoke(BrowserDebugFilter.java:7 4)

     at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePers istenceFilter.java:28)

     at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38)

     at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46)

     at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38)

     at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)

     at coldfusion.filter.RequestThrottleFilter.invoke(RequestThrottleFilter. java:126)

     at coldfusion.CfmServlet.service(CfmServlet.java:198)

     at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:8 9)

     at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)

     at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringS ervletFilter.java:42)

     at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46 )

     at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)

     at jrun.servlet.FilterChain.service(FilterChain.java:101)

     at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)

     at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)

     at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java: 286)

     at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java: 543)

     at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.ja va:203)

     at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPoo l.java:320)

     at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.j ava:428)

     at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool. java:266)

     at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

javax.servlet.ServletException: ROOT CAUSE:

java.lang.NoClassDefFoundError: Could not initialize class

com.cybersource.ws.client.Signature

     at com.cybersource.ws.client.Client.soapWrapAndSign(Client.java:200)

     at com.cybersource.ws.client.Client.runTransaction(Client.java:103)

     at com.cybersource.ws.client.Client.runTransaction(Client.java:53)

     at CyberSource.runTransaction(CyberSource.java:32)

     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39)

     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25)

     at java.lang.reflect.Method.invoke(Method.java:597)

     at coldfusion.runtime.java.JavaProxy.invoke(JavaProxy.java:87)

     at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:2272)

     at cfcheckout22ecfm2002022632.runPage(/usr/local/apache2/htdocs/sfs/cybe rsource_api_test/checkout2.cfm:42)

     at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:196)

     at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:370)

     at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65)

     at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:279 )

     at coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40)

     at coldfusion.filter.PathFilter.invoke(PathFilter.java:86)

     at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:70)

     at coldfusion.filter.BrowserDebugFilter.invoke(BrowserDebugFilter.java:7 4)

     at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePers istenceFilter.java:28)

     at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38)

     at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46)

     at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38)

     at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)

     at coldfusion.filter.RequestThrottleFilter.invoke(RequestThrottleFilter. java:126)

     at coldfusion.CfmServlet.service(CfmServlet.java:198)

     at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:8 9)

     at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)

     at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringS ervletFilter.java:42)

     at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46 )

     at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)

     at jrun.servlet.FilterChain.service(FilterChain.java:101)

     at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)

     at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)

     at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java: 286)

     at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java: 543)

     at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.ja va:203)

     at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPoo l.java:320)

     at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.j ava:428)

     at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool. java:266)

     at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

     at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringS ervletFilter.java:70)

     at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46 )

     at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)

     at jrun.servlet.FilterChain.service(FilterChain.java:101)

     at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)

     at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)

     at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java: 286)

     at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java: 543)

     at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.ja va:203)

     at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPoo l.java:320)

     at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.j ava:428)

     at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool. java:266)

     at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

Yes, my sysadmin installed the java API client on the server, and did some

test API transactions to the test cybersource server, which were successful.

The Java API client has some script files to run the pure Java version of

the API to send a transaction to Cybersource. I was able to log into the

Cybersource business center to confirm that the transactions were received.

The next step was to integrate Coldfusion into the process. The coldfusion

option piggybacks on the Java Client, and generates a Java object inside

coldfusion from the Java API client on the server. The sample Coldfusion

templates which were provided with the API download were put on the server,

and then they were edited to point to the API properties file. After an

initial failure, I realized those JAR files needed to be made available in

the class path and we copied them over.

After that, the initial class not found exceptions ceased, but instead now

we get this 500 error.

The following is an excerpt from some of the (limited) actual instructions

for the Coldfusion portion of the Java/Coldfusion Simple Order API for

Cybersource.

The ColdFusion directory contains the additional jar file, cybs-cfm.jar,

that

you need to include in your CLASSPATH in order to integrate the Simple Order

API for Java into your ColdFusion applications.  It also contains samples

for

both Name-Value Pair and XML clients.  They have been tested with ColdFusion

MX 7.

To add the CyberSource jar files to the CLASSPATH used by ColdFusion, edit

the

file /runtime/bin/jvm.config and append the full path of the

following jar files to the value of "java.class.path":

cybsclients14.jar OR cybsclients15.jar (depending on the JVM version)

cybssecurity.jar

xercesImpl.jar

cybs-cfm.jar

For example, on Windows, if you installed the Simple Order API in

"c:\Program Files\CyberSource Corporation\simapi-java-5.0.2", you would add

the

following paths:

c:/Program Files/CyberSource

Corporation/simapi-java-5.0.2/lib/cybsclients14.jar;c:/Program

Files/CyberSource

Corporation/simapi-java-5.0.2/lib/cybssecurity.jar;c:/Program

Files/CyberSource

Corporation/simapi-java-5.0.2/lib/xercesImpl.jar;c:/Program

Files/CyberSource Corporation/simapi-java-5.0.2/coldfusion/lib/cybs-cfm.jar

You will need to restart the ColdFusion application server in order for your

change to take effect.  On Windows, you will need to restart the "ColdFusion

MX 7 Application Server" service.

There is a much older conversation here involved the xerces JAr it seems:

http://www.justskins.com/forums/coldfusion-java-guru-install-cybersour ce-java-api-79208-2.html

Anyway - so back to your suggestions, from where should Coldfusion end up

references the xerces JAR? If I remove it from the Classpath, and the

jvm.config file, and remove the physical jar file from Web-INF/lib, where

will it find it? Won't it be nowhere then?

(thank you for your help btw - it is much appreciated)

dcsonka wrote:

 

Oh, are suggesting to have the API Client reference the original xerces JAR file that Coldfusion had already? And to not use the one that came with the files in the API Client download?

 

 

Also - we didn't make any changes to the class path at all, all we did was move the JAR files that came with the API download, into the coldfusionroot/WEB-INF/lib directory.

Yes, exactly.   Sometimes having two versions of a jar in the classpath causes the jvm to get confused and fall down.  By removing the extra version, hopefully it will eliminate the error. If indeed that is the problem here.

That is okay about the classpath.  If you did not change the jvm.config file, removing the jar from WEB-INF/lib should do the trick.  (The reason is WEB-INF/lib is already in CF's classpath. So it knows it should load any jars it finds in that folder).

removed the xercesImpl.jar from the path /opt/coldfusion8/wwwroot/WEB-INF/lib/ and restarted coldfusion.

Now getting the errors:

500

ROOT CAUSE: 
java.lang.NoClassDefFoundError: org/apache/xerces/dom/DocumentImpl

javax.servlet.ServletException: ROOT CAUSE: 
java.lang.NoClassDefFoundError: org/apache/xerces/dom/DocumentImpl

From that older thread - from the support person -

"The xerces version that comes with the CDK is the important portion here, as

it is required in order to sign the soap message with the RSA libraries that
are part of the client. If any other xerces version is used besides the one
included in the CDK, then it will fail with the java.lang.null that is commonly
seen."

would that be synonamous with the error I was just now getting after removing that xerces JAR?

version is CF 8, my sysadmin knew it had to be rebooted

would that be synonamous with the error I was just now getting after removing that xerces JAR?

 

version is CF 8, my sysadmin knew it had to be rebooted

I do not think so. Not unless you are seeing a null exception somewhere further down the chain. That comment refers to a NullPointerException (ie something is totally undefined) and the error you are getting is NoClassDefFoundError. The latter usually means there was a problem loading something, not necessarily that it could not be found.  But the causes vary.

But in any case, that version _should_ be okay.  According to the MANIFEST files the CF version seems the same as the cybersource version.   Did you check the logs? Maybe they contain a more detailed error.

It almost seems like you were better off with the first error.  Where there any "Caused by:" details for the first error or just:

javax.servlet.ServletException: ROOT CAUSE:

java.lang.NoClassDefFoundError: Could not initialize class

com.cybersource.ws.client.Signature

....

Yeah, I couldn't find anything referencing a "caused by" in the preceding error reports.

The server that the java client and coldfusion code is running on, all uses the same JRE. That server is only used for coldfusion, and has just the one JRE installed.

If only thr Cybersource support staff was as responsive and helpful as you, you've been an awesome help, I just wish they could chime in and give some insight too.

That is an interesting idea! I'm going to see what they have to tell me,

unfortunately they are also 3 hours behind me in timezone. If they have no

credible solution, I may try your idea as a last resort. I'll keep updating

this thread.

So, the customer support group said to update the jvm.config file to have

the class path reference the JAR files, for it to work. I figured having

them in WEB-INF/lib would have been sufficient, but they insisted it needed

to be done.

The sysadmin updated the jvm.config file and the preceding error did not

occur (so I guess that is a small victory).

Now however, we are getting a new error, relating to a certificate:

Exception Message: sun.security.validator.ValidatorException: PKIX path

building failed: sun.security.provider.certpath.SunCertPathBuilderException:

unable to find valid certification path to requested target

This doesn't look like a colfusion issue, offhand, but I'm not sure.

The sysadmin got instructions from Cybersource on the certificate matter:

It looks like it all basically came down to some steps that the sysadmin

neglected to do during installation.1) Proper updating of the class path to

point to the necessary jar files

2) Proper installation of the root certificate for Cybersource

Once those two things were done, I was able to make an API call from

coldfusion.

Thanks to you as well- your help was most appreciated!