Re: [C++/Java] Interop update
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
Re: [C++/Java] Interop update
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/
Re: [C++/Java] Interop update
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
Re: [C++/Java] Interop update
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
Jira permissions, was: [C++/Java] Interop update
On Jul 21, 2006, at 6:41 AM, Frank Budinsky wrote: 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. It may be available to folk in the tuscany-developers group which includes committers but also other active contributors as well. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++/Java] Interop update
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(
