I've got to that age where I've started replying to my own mails. Oh dear.
Looking back at the JIRAs raised when doing the interop testing a couple of weeks ago I may have missed a detail. When trying to get round JIRA505, which describes the problem with having xsi:type in the wrapper element, I also inadvertently made a temporary change to stop C++ producing duplicate namespace definitions. This may be a problem in its own right. I have raised a separate JIRA (http://issues.apache.org/jira/browse/TUSCANY-570). Also, with JIRA505 itself, comments from the SDO team indicate that SCA/Java may be doing something slightly strange with the way it loads types in at configuration time ready for when SOAP messages are received. How do I reclassify this bug to associate it with Java/SCA also so that it doesn't fall between the SCA and SDO teams? I realize that this stuff is a little in flux at the moment due to the changes in head but we still need to make interop work when head settles down again. Regards Simon On 6/29/06, Simon Laws <[EMAIL PROTECTED]> wrote:
Ok, I had some success over the last couple of days in getting C++ SCA to talk to Java SCA. The executive summary is that we got a message from C++ client to C++ SCA service on to a Java SCA service and all the way back again. Yippeee. The scenario is based on the BigBank for C++ sample that Ed has been working on. Here is what we had to do to make it work... The sample is as follows. C++ Client --> C++ AccountService/AccountDataService --> Java StockQuoteService The intention is to add a PHP client in the future but that is not there yet. In theory we could also add the Java BB client to the front end but the java interface to BB was more complex that we wanted to tackle in the first instance so that is something else that could be done if we choose. We chose to make a new Java StockQuoteService as the interface is so simple. We took the external WSDL and implemented that, i.e. the "float getQuote (String)" interface. The current Java Big Bank sample does provide a local Java StockQuoteService implementation but it seems that this has a slightly different interface, i.e. it implements getQuotes which takes and returns arrays. Anyhow we made a new external service which is in itself an SCA module with a java implementation and exposing a service with the getQuote interface. We also made a java client to test this with. There are no patches for these yet as we are not sure where to put them. My vote is to put them in the java/testing/interop dir but am open to suggestions. The C++ BB sample is expecting an external service with the getQuote interface so we changed the sca.module file to point to the new Java SCA StockQuoteService running in the Java M1 configured tomcat container. There were a few problems along the way to getting a complete end to end run. 1/ The use of doc/lit/wrapped caused confusion in the first instance and combined with the outstanding problem that C++/SDO cannot handle root elements with only simple types in ( http://issues.apache.org/jira/browse/TUSCANY-488) there was some debate about what the WSDL for the account service should look like. This is an except of what we ended up with for the type descriptions... <xsd:complexType name="GetAccountReportType"> <xsd:sequence> <xsd:element name="customerID"> <xsd:complexType> <xsd:sequence> <xsd:element name="customerID" type="xsd:string" /> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:element name="getAccountReport" type="tns:GetAccountReportType"/> <xsd:complexType name="AccountReport"> <xsd:sequence> <xsd:element name="checking" type="tns:CheckingAccount" maxOccurs="unbounded"/> <xsd:element name="savings" type="tns:SavingsAccount" maxOccurs="unbounded"/> <xsd:element name="stocks" type="tns:StockAccount" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:element name="getAccountReportResponse"> <xsd:complexType> <xsd:sequence> <xsd:element name="accountReport" type="tns:AccountReport"/> </xsd:sequence> </xsd:complexType> </xsd:element> The odd extra level of CustomerId came from the confusion around 488 but I believe could be removed (http://issues.apache.org/jira/browse/TUSCANY-507) but the client has been coded this way currently so we didn't try and fix it. 2/ Another thing to note about the WSDL is the use of anonymous types. My preference is not to do this by default but of this doesn't work at present ( http://issues.apache.org/jira/browse/TUSCANY-500 ). 3/ Changed GetQuote to getQuote in StockQuoteService_StockQuoteExternal_Proxy.cpp and associated StockQuoteExternal files ( http://issues.apache.org/jira/browse/TUSCANY-508) 4/ Axis2Client.cpp ln 282 LOGINFO_2 causes an edna in the case where the server being called returns an error. I changed this to a LOGINFO, i.e. no var args, and carried on. I didn't go back and try it with successful responses. (http://issues.apache.org/jira/browse/TUSCANY-509) 5/ StockQuoteExternalService.h /StockQuoteServiceImpl.cpp has incorrect return type for getQuote const char * should be float. ( http://issues.apache.org/jira/browse/TUSCANY-510) 6/ The C++ SDO implementation produces XML with an xsi:type attribute on the root element. The java container doesn't like this ( http://issues.apache.org/jira/browse/TUSCANY-505). We changed the C++ implementation to take these out temporarily to see if we could progress. SDOXMLWriter.cpp ln722 ish replace rc = xmlTextWriterWriteAttributeNS(writer, SDOXMLString("xsi"), SDOXMLString("type"), NULL, /*SDOXMLString(" http://www.w3.org/2001/XMLSchema-instance";),*/ SDOXMLString(dataObject->getType().getName())); with if (!isRoot) { rc = xmlTextWriterWriteAttributeNS(writer, SDOXMLString("xsi"), SDOXMLString("type"), NULL, /*SDOXMLString(" http://www.w3.org/2001/XMLSchema-instance";),*/ SDOXMLString(dataObject->getType().getName())); } There is no JIRA here as this is just a temporary change in my code base to get things moving. 7/ The C++ SDO implementation produces XML with no namespace prefixs. The Java implementation requires these (http://issues.apache.org/jira/browse/TUSCANY-491 ). We fixed this temporarily by doing the following. SDOWriter.cpp ln 680 ish (I say ish as I've added couts which have messed up the line numbers Change the 1st NULL to a sensible prefix value, e.g. rc = xmlTextWriterStartElementNS(writer, /*NULL*/ (const unsigned char*)"tns", elementName, elementURI); Again no specific JIRA as more investigation needs to be done on 491 8/ At this point we were able to get message from C++ client to C++ service to Java server back to C++ Server but it failed on the last hop with a nasty memory error down inside libxml2. A bit of careful commenting out of code narrowed down the cause, in this case, to here Axis2Client.cpp ln 149 /* if (svc_client) { AXIS2_SVC_CLIENT_FREE(svc_client, env); svc_client = NULL; } */ Its not clear what is going on or whether this is the actual cause but we are able to get an end to end run by commenting this line out. Needs further detailed investigation to determine if this is causing memory corruption of something else is by, for example, freeing something twice. ( http://issues.apache.org/jira/browse/TUSCANY-511) So all in all a bit of a journey but it gives us confidence that it will work. The Big Bank sample of course only provides a test with very simple messages. Andy is, I be live, going to take a look at passing all of the interop XML docs back and forth across the web service interface in a separate test. Regards Simon
