A little more context: When the CXF-generated Javascript code generates a WSDL service call and receives a chunked response, any other call that returns from the server on that same port/client steps on the client's handling on a still-being-received chunked response. So while the entire chunked attachment does arrive in the browser, the CXF client handling the response loses its internal reference and thus never properly populates the variable the data is supposed to be assigned to when constructing/deserializing the object in the onsuccess method call.
Maybe this is an inherent limitation of Javascript that CXF can't overcome, but it would be nice to know if there's a better way to deal with it rather than having to chain multiple service calls together if they have the potential to return large amounts of data. -A -----Original Message----- From: Bagwell, Allen F [mailto:[email protected]] Sent: Thursday, October 20, 2011 1:33 PM To: [email protected] Subject: bad behavior when deserializing same complex object with binary attachment I have a CFX problem. Figured out a work-around, but not certain if I've encountered a bug. I have a web service being implemented through WSDL. We are using CXF to generate the client-side Javascript code. One display on my web page involves calling two methods, both of which use the same WSDL service and both return the same complex type portDataMap which contains a dataWrapper which in turn contains a data field that will be populated by the response. If I call either one of these methods in isolation, the returned portDataMap is properly deserialized along with its binary data payload (actually a very long JSON string) through the CFX-generated code. However, if I call one right after the other, the last one to return from the server produces this error: 503 Uncaught TypeError: Cannot read property '[email protected]' of undefined org_apache_cxf_deserialize_MTOM_or_base64 templateRunManager:503 ws_api_service_temp_common_dataWrapper_deserialize templateRunManager:16037 ws_api_service_temp_common_portDataMapEntry_deserialize templateRunManager:16505 ws_api_service_temp_common_portDataMap_deserialize templateRunManager:16166 ws_api_service_temp_trm_getResultsResponse_deserialize templateRunManager:11443 ws_api_service_temp_trm_getResultsResponse_deserializeResponse templateRunManager:19652 ws_api_service_temp_trm_getResults_op_onsuccess templateRunManager:19584 client.onsuccess templateRunManager:19625 org_apache_cxf_client_onReadyState queueManager:915 req.onreadystatechange The undefined element in the org_apache_cxf_deserialize_MTOM_or_base64 method is the parts array. It is not being populated by reading, splitting up the multipart message attachment, and assigned it to the array: var cid = href.substr(4); var partobject = this.client.parts[cid]; I've confirmed that the response coming back from the server DOES contain the data as expected (easy enough to see the JSON string by looking through the Chrome debugger at the response attachment). The workaround to this problem appears to be that as long as I nest the second WSDL server call at the end of the success method of the first WSDL service call - making the call for the second depend on the successful response of the first - the CXF client appears to populate the parts array correctly and my methods both work. Is this expected behavior for CXF auto-genn'ed Javascript code? Is there a step I'm missing in making sure my client is ready to receive the next CFX/WSDL service response? Thanks! -A ------------------------------------------------------- Allen F. Bagwell Sandia National Laboratories - CA [email protected]<mailto:[email protected]>
