Skip to main content
elisabethf82215657
elisabethf82215657
Inspiring
December 14, 2020
Answered

org.xml.sax.SAXException: No deserializer for {http://rpc.xml.coldfusion}CFBoolean

  • December 14, 2020
  • 1 reply
  • 2460 views

We are going to migrate several servers from Coldfusion 2016 to 2018.

During our tests we have the following problem:

We use a SOAP webservice for communication between two servers.

The caller of the webservice is still CF 2016, the called server was migrated to 2018. Since the migration the webservice throws the following error if the returned data contain boolean elements:

 

<br> <pre>AxisFault faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException faultSubcode: faultString: org.xml.sax.SAXException: No deserializer for {http://rpc.xml.coldfusion}CFBoolean faultActor: faultNode: faultDetail: {http://xml.apache.org/axis/}stackTrace:org.xml.sax.SAXException: No deserializer for {http://rpc.xml.coldfusion}CFBoolean at org.apache.axis.encoding.DeserializerImpl.onStartElement(DeserializerImpl.java:453) at org.apache.axis.encoding.DeserializerImpl.startElement(DeserializerImpl.java:393) at org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1048) at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:165) at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.java:1141) at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:236) at org.apache.axis.message.RPCElement.getParams(RPCElement.java:384) at org.apache.axis.client.Call.invoke(Call.java:2448) at or... ''</pre>

 

in another case we recived this error:

<br> <pre>AxisFault faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException faultSubcode: faultString: org.xml.sax.SAXException: Found character data inside an array element while deserializing faultActor: faultNode: faultDetail: {http://xml.apache.org/axis/}stackTrace:org.xml.sax.SAXException: Found character data inside an array element while deserializing at org.apache.axis.encoding.ser.ArrayDeserializer.characters(ArrayDeserializer.java:502) at org.apache.axis.encoding.DeserializationContext.characters(DeserializationContext.java:966) at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:177) at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.java:1141) at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:236) at org.apache.axis.message.RPCElement.getParams(RPCElement.java:384) at org.apache.axis.client.Call.invoke(Call.java:2448) at org.apache.axis.client.Call.invoke(Call.java:2347) at org.apache.axis.cl... ''</pre>

 

The code of the webservice was not changed during migration.

 

Can anybody help?

 

    This topic has been closed for replies.
    Correct answer Charlie Arehart

    Thanks for the quick reply!

    Sorry, I have to ask a naive question: This webservice is the call of a remote cffunction with returntype struct.

    The SOAP response is generated by Coldfusion out of the return data, so Coldfusion defines the types used here! And the interpretation of Coldfusion 2016 seems to be different from 2018.

    Do I have any influence on the types used here?

     

    We have a handful of web services with different clients, not only internally used ones. This exactly is my concern, that external clients will also have problems with the new way data are returned! Can I influence this?


    Here's good news, I think. Yes, Elisabeth, it seems you CAN influence that. After seeing your replies today (and rereading all our and BKBKs interactions since Dec 14th) and doing a bit more digging, it does indeed seem you are being hit by a change in behavior in CF2018 (though again, not technically a "bug").

     

    The change and how to revert it are discussed here:

     

    https://helpx.adobe.com/coldfusion/developing-applications/the-cfml-programming-language/using-coldfusion-variables/data-types-developing-guide.html#data-type-preserve

     

    Note that there are multiple steps:

    1. implement the jvm arg (carefully) that is indicated in the doc (such as by editing the jvm.config in your cfusion/bin folder) 
    2. Then stop cf
    3. Then remove all currently compiled cf classes (this is most easily done--and revertible, if needed--by simply renaming the cfusion/WEB_INF/cf classes folder - - NOT it's sibling classes folder. Cf will recreate the cfclasses folder on restart). This step is needed to remove the previously compiled Java classes that all cf pages are turned into. This setting affects that compilation. 
    4. Then start cf and test things

     

    Let us know how it goes. 

     

    Of course, making a global change like that has to be considered with care: in changing that behavior, you could be negatively effect code that was BENEFITING from the change Adobe made. But in your case, just moving to cf2018, that's not likely an issue. I point this out as much for other readers now and in the future.

     

    And fwiw, this issue would seem to affect as well those moving to cf2021 from cf2016 or earlier, so it's a very interesting problem and (I hope) solution. 

     

    As for why we may not have heard of others hitting this before now (3 years into the life of cf2018), and therefore not have offered it readily as a solution back on Dec 14, I suspect there's an explanation:  existing code running entirely within cf (caller and called) would hardly be affected, and calls via Ajax and json may not be AS affected.

     

    But web services are so very datatype-specific as to be more sensitive to it. And it may be only some types, like this CFBoolean, all of which may diminish the number of people who would have hit it, reported it, and had news shared--like this post will do for folks going forward. 

     

    Hope to hear this is indeed the solution for you. 

     

     

    1 reply

    Charlie Arehart
    Charlie Arehart
    Community Expert
    December 14, 2020

    Elisabeth, there are at least 3 things to consider/do. (If you may be thinking there's some bug you're hitting about web svcs in general on cf2018, I don't think so.) 

     

    Instead, as a preface, there may well be a single configuration change needed on the new server, but more likely the problem is that some OTHER unexpected error is happening (in the attempt to run the web service on the new server, perhaps related to something NOT specific to web services at all), and you just are not seeing that error: instead what you ARE seeing may be the calling cf2016 server tripping over that unexpected error. That is a common problem in such integration processing. 
     
    So first I'd recommend you check on the cf2018 server (serving the web service), to see if there is any error tracked there when the web service is called. Look in its cf logs. But note that if any error handler may have implemented, then the logs may not show the error. You'd need to then find where such error handling may be tracking such errors.

     

    Since that could be challenging, the next step would be to try to call the web service directly, rather than through cfml. You could look at the cfml calling the web service, determine the url and any arguments passed in, and then call the cf2018 server's web service directly. You can try it from a browser, or you may find you need a client tool like soapui or postman. That may show the error that cf2018 is returning, rather than how currently you're seeing the error from your cf2016 code when it's not handling that error well.

     

    Finally, it's POSSIBLE that you may simply need to configure the cf admin in 2018 to be the same as 2016, regarding the setting on the web services page, about the default web service "level" (1 or 2). That's simple to check and try, but it's too involved to elaborate further here (the difference, the ability to control that also at the app or code level, etc). So for now, just compare your cf2016 and cf2018 servers regarding that value. Are they the same? If not, and you change it, does that help?

     

    Someone may wonder why I didn't offer that first. My reasoning is that the error shown doesn't look like one common to that setting being the cause. And either way, the first two suggestions above will serve Elisabeth (and anyone with such a migration) regarding still other web svc errors that could happen and which could have very different causes.

     

    Let us know how that goes. I could offer much more on the points above, but some prefer brevity. I'll add also that I could easily help you solve this directly (via remote consulting), likely in as little as 15 mins, if interested. No worries if you aren't/can't/won't, in which case I hope the above gets you going.

    /Charlie (troubleshooter, carehart. org)
    elisabethf82215657
    elisabethf82215657Author
    Inspiring
    December 15, 2020

    Thanks a lot for the quick response, Charlie!

    Unfortunately there is a lot of traffic from another application also using a webservice and throwing exceptions. We are trying to get that switched off to be able to have clean log files and search for exceptions in this case.

     

    What I can add to the description (and this is the reason why I do not believe there are any exceptions here):

    We used a test script to call the webservice and get the complete SOAP response. This response does not show any error, the data we receive are correct and complete. The only difference we can see to the same test on the production server (which is still Coldfusion 2018) is that the boolean values were then returned as strings and are now returned as cfboolean.

     

    Also of course we checked the wsversion parameters everywhere (before asking here), the version is 1 on all servers (and not changed in the code).

     

    I did not think of a Coldfusion error but rather of some configuration option that we may have missed during the upgrade.

     

    elisabethf82215657
    elisabethf82215657Author
    Inspiring
    January 5, 2021

    Welcome back, Elisabeth. I hope you had a wonderful time.

     

    I had asked if you could share the code because I suspected that the error might have to do with namespace. The 2 dumps you've shared in fact confirm my suspicion.

     

    When you design a web service, you have to assume that any client - Java, C#, PHP, ASP, Python, etc. - may use it. Hence, general best-practice requires that you use universal types for the variables. These types are string, integer, double, boolean and so on. This is particularly relevant for responses from the web service. They should not include ColdFusion-specific types. 

     

    That is apparently what happened. The response of your service has 2 ColdFusion-specific types. These are difficult for the client to convert, even if the client is ColdFusion itself. You can see them by navigating to:

     

    RESP > soapenv:Envelope > soapenv:Body > ns2:globalCallResponse > globalCallReturn > item[4] > Data > item[3] > bSuccess

     

    and 

     

    RESP > soapenv:Envelope > soapenv:Body > ns2:globalCallResponse > globalCallReturn > item[4] > Data > item[2] > QRData

     

    You used, for the first, the ColdFusion-specific type defined by:

     

    xmlns:ns5 http://rpc.xml.coldfusion
    xsi:type ns5:CFBoolean

     

    and, for the second, the ColdFusion-specific type defined by:

     

    xmlns:ns4 http://rpc.xml.coldfusion
    xsi:type ns4:QueryBean

     

    which suggests that the rsponse included a ColdFusion query object. You can correct the first by changing the attributes of bSuccess to:

     

    xmlns:soapenc http://schemas.xmlsoap.org/soap/encoding/
    xsi:type soapenc:boolean

    or 

    xmlns:soapenc http://schemas.xmlsoap.org/soap/encoding/
    xsi:type soapenc:int

     

    You can correct the second by serializing the query, then returning the (serialized) string instead, using the type:

     

    xmlns:soapenc http://schemas.xmlsoap.org/soap/encoding/
    xsi:type soapenc:string

     

    The client will of course have to deserialize this to obtain the query.


    Thanks for the quick reply!

    Sorry, I have to ask a naive question: This webservice is the call of a remote cffunction with returntype struct.

    The SOAP response is generated by Coldfusion out of the return data, so Coldfusion defines the types used here! And the interpretation of Coldfusion 2016 seems to be different from 2018.

    Do I have any influence on the types used here?

     

    We have a handful of web services with different clients, not only internally used ones. This exactly is my concern, that external clients will also have problems with the new way data are returned! Can I influence this?

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices