You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2006/07/21 13:44:35 UTC
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 <si...@googlemail.com> 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
>
>
>
>
Jira permissions, was: [C++/Java] Interop update
Posted by Jeremy Boynes <jb...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++/Java] Interop update
Posted by Frank Budinsky <fr...@ca.ibm.com>.
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" <si...@googlemail.com> 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 <fr...@ca.ibm.com> wrote:
> >
> > Simon,
> >
> > I reassigned TUSCANY-505 to the SCA component for further
investigation.
> >
> > Frank.
> >
> > "Simon Laws" <si...@googlemail.com> 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 <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++/Java] Interop update
Posted by Simon Laws <si...@googlemail.com>.
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 <fr...@ca.ibm.com> wrote:
>
> Simon,
>
> I reassigned TUSCANY-505 to the SCA component for further investigation.
>
> Frank.
>
> "Simon Laws" <si...@googlemail.com> 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 <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [C++/Java] Interop update
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Simon,
I reassigned TUSCANY-505 to the SCA component for further investigation.
Frank.
"Simon Laws" <si...@googlemail.com> 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 <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org