Upgrading Standard to Enterprise breaks .NET object method execution

[carmenj17747405]

We just upgraded our CF 10 Standard to CF 13 Enterprise over the weekend and are trying to hammer out some strange bugs.

One example is where we are hitting a .NET web service which returns an object. When we try to execute the .getString() method on this object the value returned is "undefined":

<cfset var recInfo = structnew()>

<cfset var schemaName = "">

<cfset var theArray = arraynew(1)>    

<cfinvoke webservice="#this.JobTicketWS#" method="GetSchemasNames" returnVariable="result" wsversion="1">

     <cfinvokeargument name="inUsername" value="#this.inUserName#">

     <cfinvokeargument name="inPassword" value="#this.inPassword#">

     <cfinvokeargument name="inTicketID" value="#arguments.jobTicketID#">

</cfinvoke>

<cfif result.getString() neq "">

     <cfset theArray = result.getString()>

     <cfset schemaName = theArray[1]><!--- if it's not empty it will always be 1 --->

</cfif>

What the value I am expecting is a single-dimension array of a string.

The error is "theArray is undefined" - when I explicitly dump #result.getString() I get "undefined"

I can execute another function on this very same object that returns a string and it works just fine. Only the methods that return an array that are breaking.

We're on Windows Server 2012 and apparently Java 10 after the upgrade. (we were on Java 8) with a single CF node.

Any ideas are appreciated.

[Charlie Arehart]

Carmen, what do you see if you just cf dump result. Getstring(), right after the cfinvoke? And then what about that, if anything, is shown in a dump of result itself? 

[carmenj17747405]

If I dump the result from the webservice call, I see object:

getSchemaNames result - object of XMPieWSAPI.ArrayOfString
Class Name	XMPieWSAPI.ArrayOfString
Methods	Method Return Type equals(java.lang.Object) boolean getDeserializer(java.lang.String, java.lang.Class, javax.xml.namespace.QName) org.apache.axis.encoding.Deserializer getSerializer(java.lang.String, java.lang.Class, javax.xml.namespace.QName) org.apache.axis.encoding.Serializer getString() java.lang.String[] getString(int) java.lang.String getTypeDesc() org.apache.axis.description.TypeDesc hashCode() int setString(java.lang.String[]) void setString(int, java.lang.String) void

Immediately after the call I am dumping this:

<cfdump var="#result#" label="getschemanames result">

<cfif isArray(result.getString())>

     <p>an array!</p> <!--- this, of course, never hits --->

</cfif>

<cfoutput>

     <p>result.getTypeDesc() = #result.getTypeDesc()#</p>

</cfoutput>

<p>result.getString() = <cfdump var="#result.getString()#" label="result.getString()"></p><cfabort>

Which results in this output:

result.getTypeDesc() = org.apache.axis.description.TypeDesc@37fe0266

result.getString() = undefined

[carmenj17747405 · Accepted solution]

FYI, somehow this one little change fixed the problem:

WAS:

<cfif result.getString() neq "">

     <cfset theArray = result.getString()>

     <cfset schemaName = theArray[1]><!--- if it's not empty it will always be 1 --->

</cfif>

NOW:

<cfif len(result.getString()) neq 0>

     <cfset theArray = result.getString()>

     <cfset schemaName = theArray[1]>

</cfif>    

Somehow, CF sees a difference between an empty string and string of length 0.

Moving on...and thanks.

[Charlie Arehart]

I understand you're moving on, but for the sake of others (or if you're interested): while that change may work for you, it does not explain why the getstring returned undefined. And if cf10 had not also done that, then THAT is the difference it would seem you should be resolving.

I mean that the same prior IF criteria might have failed in 10 *also*, if the function had returned undefined in 10.

But again, you may not for now care to prove or solve that. I just wanted to put that out there. (And it's also why I proposed that you dump the result variable itself, in case there may be other differences between that result in cf10 vs 2018.)

Finally, you may help yourself and others by referring to cf2018 rather than cf13 (even if that's the download filename you got--and even if from Adobe). See the main Adobe CF site (and installer screens and cf admin screens) which all refer to CF2018, not 13.

As always, just trying to help.

[carmenj17747405]

I am unable to explain why one version of CF resolves a variable differently than another version, and I'm unsure how I would go about solving that, but thanks for your input and answering my post. CF2018 it is!

[Charlie Arehart]

I appreciate that you feel you can't explain the difference. I've been simply proposing  that (unless and until you choose only to "move on)  that you (or someone with a similar problem) could at least start by cfdump'ing that "result" var in both 10 and 2018 to see what they show. You might find some key differences that perhaps COULD be explained.