Hi Simon, On the left side of the window, under "Operations", there is a link "Edit this issue". If you don't see it, then it must be only available to committers.
Frank. "Simon Laws" <[EMAIL PROTECTED]> wrote on 07/21/2006 09:28:15 AM: > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
