Hi Frank, Thanks for that. How did you do it. I looked at the JIRA and I could see how you change the category like that? Is it a committer thing?
Regards Simon On 7/21/06, Frank Budinsky <[EMAIL PROTECTED]> wrote:
Simon, I reassigned TUSCANY-505 to the SCA component for further investigation. Frank. "Simon Laws" <[EMAIL PROTECTED]> wrote on 07/21/2006 07:44:35 AM: > 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 > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
