[rules-users] .NET WCF unable to deserialize response from Drools Camel Server example 6.2.0 snapshot

Clark Wilson wilsonch0 at yahoo.com
Mon Aug 4 18:29:48 EDT 2014


Drools, Eclipse, Tomcat, and WCF are all new to me, so I may be missing something obvious. Questions at the bottom, after the problem description.

I deployed the Drools Camel Server WAR file in a Tomcat 7 server I'm running within Eclipse under Windows 7. Using Visual Studio 2013 and System.ServiceModel 4.0.0.0 I generated a client from the WSDL. I fixed a problem with serialization and am getting an error on deserialization. The inner exception says "End element 'return' from namespace 'http://soap.jax.drools.org/' expected. Found text '<'. Line 1, position 189."

The WSDL (obtained from http://127.0.0.1:8080/drools-camel-server-example-6.2.0-SNAPSHOT/kservice/soap?wsdl) says there should be a thing named "return" there.

<xsd:element name="executeResponse" type="tns:executeResponse"/>
<xsd:complexType name="executeResponse">

    <xsd:sequence>

        <xsd:element name="return" type="xsd:anyType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>


I am unable to convince the Visual Studio debugger to show me the text it is trying to deserialize. But a colleague used another tool to get a copy of the message body and it seems in addition to "return" there is a "fact-handle". (This is the weak link in the evidence chain; I didn't redo this today.) (The "Hello:" text is what Drools is indeed sending. I changed the original drl file.)

<?xml version='1.0' encoding='UTF-8'?>
<execution-results>
    <result identifier="person1">
        <org.drools.server.Message><text>Hello:</text></org.drools.server.Message>
    </result>
    <fact-handle identifier="person1" external-form="0:1:427239608:427239608:1:DEFAULT:NON_TRAIT"/>
</execution-results>


Question1: Is the fact-handle element likely to be the cause of .NET's deserialization error?
Question 2: If so, what would I do, and where, to fix the problem? Does the WSDL need to be different? Does fact-handle need to be omitted? Does some .NET option need to be changed?
Question 3: If that's not the cause, how can I identify the real problem?

Thanks in advance,
Clark Wilson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20140804/8d2de01f/attachment.html 


More information about the rules-users mailing list