Skip to main content
Participant
October 5, 2006
Question

Urgent help needed w/ Java WS code

  • October 5, 2006
  • 2 replies
  • 587 views
I’m attempting to access Salesforce.com webservices API in Cold Fusion using SFDC’s Java API. I’m running a developer edition standalone that I installed on my windows xp laptop a few days ago. I’ve put the SFDC .jar in ..\wwwroot\web-inf\lib. My cfm looks like this:

<cfobject action="create" type="java" class="com.sforce.util.login.EnterpriseLoginBean" name="sfdc"/>
<cfset x=sfdc.setUsername("username")/>
<cfset x=sfdc.setPassword("password")/>
<cfset x=sfdc. initByUsername ()/>
<cfoutput>#sfdc.getLoginStatus()#</cfoutput>

EnterpriseLoginBean is a simple utility class supplied by SFDC as a wrapper for a soap session. When I load this page I just get back a 500 Internal Server Error or 500 null Jrun Servlet Error. But when I look at c:\cfusionmx7\runtime\logs\coldfusion-event.log I see this stack trace:

[1]org.apache.commons.logging.LogConfigurationException: java.lang.ClassCastException
at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:558)
at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:345)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:409)
at org.apache.axis.components.logger.LogFactory.getLog(LogFactory.java:76)
at org.apache.axis.handlers.BasicHandler.<clinit>(BasicHandler.java:81)
at org.apache.axis.client.Service.getAxisClient(Service.java:143)
at org.apache.axis.client.Service.<init>(Service.java:152)
at com.sforce.soap.enterprise.SforceServiceLocator.<init>(SforceServiceLocator.java:10)
at com.sforce.util.login.EnterpriseLoginBean.initByUsername(EnterpriseLoginBean.java:218)
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:324)
.
.
.
.


On searching for answers to this problem I discovered ColdFusion Technote: Conflict with Apache Commons Logging libraries in third party applications throws LogConfigurationException, Macromedia issue 55821.

“ColdFusion MX 7 uses Apache Commons Logging version 1.0.2. Third party applications may be packaged with their own, newer version of Commons Logging. When ColdFusion starts, the ColdFusion MX classes are loaded into the classpath first. When the third party application tries to use the older ColdFusion logging libraries, ColdFusion MX throws an org.apache.commons.logging.LogConfigurationException: java.lang.ClassCastException.”

And with this stack trace:

10/24 12:00:48 error
[1]org.apache.commons.logging.LogConfigurationException: java.lang.ClassCastException
at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:558)
at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:345)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:409)
at org.apache.axis.components.logger.LogFactory.getLog(LogFactory.java:76)
at org.apache.axis.handlers.BasicHandler.<clinit>(BasicHandler.java:81)
at org.apache.axis.client.Service.getAxisClient(Service.java:143)
at org.apache.axis.client.Service.<init>(Service.java:152)
at com.sforce.soap.enterprise.SforceServiceLocator.<init>(SforceServiceLocator.java:10)
at com.sforce.soap.enterprise.sobject.SForceBinding.createBinding(SForceBinding.java:61)
at com.sforce.soap.enterprise.sobject.SForceBinding.init(SForceBinding.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at coldfusion.runtime.StructBean.invoke(StructBean.java:391)
at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:1662)

This stack trace certainly looks a lot like what I’m getting, and, in fact, amazingly enough it also was initiated by a call to SforceServiceLocator although it appears to be an earlier version of SFDC’s java code. SFDC distributes commons-logging-1.0.4.jar with its current Java library

The suggested workaround is “modify the ColdFusion MX classpath. Add the location of the third party .jar(s) containing the newer version of the Apache Commons Logging utility to the front of the ColdFusion MX classpath (cf.class.path). ColdFusion MX then loads the third party application's newer Apache Common Logging libraries first, thereby avoiding the classfile conflict.

For example, if the JAR file for the application containing the newer Apache commons logging libraries resides in WEB-INF/cfusion/lib/thirdparty, the entry in the web.xml would be as follows:”

“<context-param id="macromedia_context_88">
<param-name>cf.class.path</param-name>
<param-value>./WEB-INF/cfusion/lib/thirdparty,
./WEB-INF/cfusion/lib/updates,./WEB-INF/cfusion/lib,
./WEB-INF/cfform/jars</param-value>
</context-param>”

So I create a new folder ..\wwwroot\web-inf\lib\thirdpartytools, copy commons-logging-1.0.4.jar into it and modify ..\wwwroot\web-inf\web.xml thusly:

<context-param id="macromedia_context_88">
<param-name>cf.class.path</param-name>
<param-value>./WEB-INF/lib/thirdpartytools,WEB-INF/../../../classes,./WEB-INF/../../lib/updates,./WEB-INF/../../lib,./WEB-INF/cfform/jars</param-value>
</context-param>

I restart the service and run my page again with exactly the same result. Any help?
This topic has been closed for replies.

2 replies

mshelmanAuthor
Participant
October 7, 2006
Thanks James for the reply. Can you clarify a bit? By jar file you mean the sforce api jar or the commons-logging jar? Then is there an adjustment for classpath? I tried a few options based on your thought but am still getting similar errors.
October 11, 2006
Why don't you actually just replace the commons-logging jar located in %cf_home%/WEB-INF/cfusion/lib? By default ColdFusion will be able to find any jars located in that directory and since you're planning on putting the new commons-logging jar file into play I don't believe there would be any way of accessing the older commons-logging jar so you might as well just swap it out entirely and see what happens.

Obviously backup your original jar incase you want to recover. Stop and restart JRun after you've done that and I would think that it'd work.

-Tim
Inspiring
October 6, 2006
Try throwing your jar file in runtime/bin