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/06/29 19:42:01 UTC
[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("
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
Re: [C++/Java] Interop update
Posted by Simon Laws <si...@googlemail.com>.
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
>
>
>
>