You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by cheng liang <ch...@hotmail.com> on 2004/05/03 01:51:21 UTC
Re: HTTP chunked problem
Hi, John,
I think you should put HTTPChunking resolution code in the channel layer.
This will make the httptransport code seems more consistent since the
difference will be solved in the below layer.
As for libwww, I have not used it yet. If it is strong enough, it would be
a good choice.
My major concern is the Class Object Deserialization problem. As I
mentioned,
the existing code could not deal with it correctly. The code could not
recognize
the "href" attribute, and treat it correctly.
The payload is as follows:
------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSc
hema-instance">
<soapenv:Body>
<ns1:getUserResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/en
coding/" xmlns:ns1="http://10.7.0.237:8080/SysPlatform/services/UserClass">
<ns1:getUserReturn href="#id0"/>
</ns1:getUserResponse>
<multiRef id="id0" soapenc:root="0"
soapenv:encodingStyle="http://schemas.xmls
oap.org/soap/encoding/" xsi:type="ns2:UsersWS"
xmlns:soapenc="http://schemas.xml
soap.org/soap/encoding/" xmlns:ns2="urn:BeanService">
<address xsi:type="xsd:string"></address>
<birthday xsi:type="xsd:date">1986-01-01</birthday>
<certificateCategory
xsi:type="xsd:string">category</certificateCategory>
<certificateNumber xsi:type="xsd:string"></certificateNumber>
<collaboratorId xsi:type="xsd:int">0</collaboratorId>
<country xsi:type="xsd:string">cn</country>
<description xsi:type="xsd:string"></description>
<email xsi:type="xsd:string"></email>
<handset xsi:type="xsd:string"></handset>
<handsetBand xsi:type="xsd:string" xsi:nil="true"/>
<msn xsi:type="xsd:string"></msn>
<nickName xsi:type="xsd:string">test2</nickName>
<password xsi:type="xsd:string">111111</password>
<postalcode xsi:type="xsd:string"></postalcode>
<province xsi:type="xsd:string">31</province>
<qq xsi:type="xsd:string"></qq>
<question xsi:type="xsd:string">hello</question>
<realName xsi:type="xsd:string"></realName>
<registerIp xsi:type="xsd:string">10.7.0.10</registerIp>
<registerTime
xsi:type="xsd:dateTime">2004-04-27T19:57:17.000Z</registerTime>
<result xsi:type="xsd:string"></result>
<secondPassword xsi:type="xsd:string" xsi:nil="true"/>
<sex xsi:type="xsd:string">0</sex>
<telephone xsi:type="xsd:string"></telephone>
<userId xsi:type="xsd:long">23</userId>
<userName xsi:type="xsd:string">test2</userName>
<website xsi:type="xsd:string"></website>
</multiRef>
</soapenv:Body>
</soapenv:Envelope>
------------------------------------------------------------
I use the following code in client stub:
Ret = (UsersWS*)m_pCall->GetCmplxObject((void*) Axis_DeSerialize_UsersWS,
(void*) Axis_Create_UsersWS,
(void*) Axis_Delete_UsersWS,
"return", 0);
I get that Ret equal NULL.
best,
Cheng Liang
>From: John Hawkins <HA...@uk.ibm.com>
>Reply-To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>CC: axis-c-dev@ws.apache.org
>Subject: Re: HTTP chunked problem
>Date: Fri, 30 Apr 2004 07:40:38 +0100
>
>
>
>
>
>Hi Cheng,
>
>fyi: Adrian, Fred Preston and I all work together so we answer questions
on
>behalf of each other :-)
>
>Yes, I saw the HTTP Content length problem but it doesn't appear to be
used
>in the code for now so I left it. However, we'll raise it on JIRA so it is
>not lost.
>
>The HTTP Transport in general has a few issues in its logic. The
underlying
>channel object isn't as good as it could be.. We had to put in some hacky
>looking code for the HTTPChunking fix. I think that a better resolution
>would be to change the underlying channel object to work properly then we
>could change the HTTPTransport to look nicer. But, we needed a fix quickly
>so we didn't do this. Again we will raise a JIRA bug report to not lose
it.
>
>
>In General - I thought that there was discussion around removing the
>HTTPTransport layer and replacing it with libwww? I think that this would
>be a really good idea. We get so much for free with that library. It is
>nice and modular and seems to not have had any new fixes for over two
years
>which (I think) shows how stable it must be.
>
>What does the dev community think to this?
>
>
>
>
>John Hawkins,
>
>
>
>
> "cheng liang"
> <chengliang2004@h
> otmail.com>
To
> axis-c-dev@ws.apache.org
> 30/04/2004 04:28
cc
>
>
Subject
> Please respond to Re: HTTP chunked problem
> "Apache AXIS C
> Developers List"
>
>
>
>
>
>
>
>
>hi, Adrian Dick,
>
>Thanks.
>
>I used this code and it work fine on windows.
>
>But I want to point that in the following code in httptransport.cpp:
>
>if((pos = strLine.find("Content-Length:")) !=
> std::string::npos)
>{
> m_intBodyLength = atoi(strLine.substr
> (pos + strlen("Content-Length: ")).c_str());
>}
>
>there is some exception.
>
>The message got from the server (apache+axis(java)+tomcat) does not
contain
>
>the
>code "Content-Length:".
>
>The http header is as follows:
>
>-------------------------------------------------------------
>HTTP/1.1 200 OK
>Content-Type: text/xml;charset=utf-8
>Transfer-Encoding: chunked
>Date: Fri, 30 Apr 2004 03:06:52 GMT
>Server: Apache-Coyote/1.1
>-------------------------------------------------------------
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
Re: HTTP chunked problem
Posted by John Hawkins <HA...@uk.ibm.com>.
We have seen a Java implementation that increases performance with large
messages using href.
John Hawkins,
Aleksander
Slominski
<aslom@cs.indiana To
.edu> Apache AXIS C Developers List
<ax...@ws.apache.org>
06/05/2004 06:10 cc
Subject
Please respond to Re: HTTP chunked problem
"Apache AXIS C
Developers List"
Susantha Kumara wrote:
>According to the XML-Pull base architecture of Axis C++ its difficult to
>support href. May need some architecture changes which will probably
>affect performance.
>
>
it is doable to support hrefs *and* do it in efficient manner:
you need to record list of unresolved forward href pointers (such as
slots in arrays)
and after deserialzing whole message fill in missing slots with actual C
pointers.
i have implemented such code in Java and i believe it is doable to port
the algorithm to C++ see:
in ArrayDeserializer when code sees href that is not yet resolved
(dctx.hasId(hid) == null)
it will record that this array slot (with index i) needs to be filled
when pointer to value
for hrefed object is available (calls dctx.addArrayFixup(o, i, kompType,
hid) to record it)
href = stag.getAttributeValueFromRawName("href");
if(href != null) {
String hid = href.substring(1); // skip # int
'#id1'
if(dctx.hasId(hid)) {
Object val = dctx.getIdValue(hid);
Array.set(o, i, val);
} else {
dctx.addArrayFixup(o, i, kompType, hid);
}
if(pp.next() != XmlPullParser.END_TAG) //skip
END_TAG
throw new DeserializeException(
"expected immediate end tag for href
element"+pp.getPosDesc());
} else {
Object val = enc.readObject(dctx, kompType, pp,
stag);
Array.set(o, i, val);
}
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsoap-java/src/java/soaprmi/soap/soaprmi/soapenc/ArrayDeserializer.java
deserializaiton context (dcts) dctx is in SoapDeserializeContextImpl and
maintians where list of fixups (unresolved forward poiunters is kept)
- see in particular hasId/getIdValue, addStruct/ArrayFixuo(), and
fixup() methods in
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsoap-java/src/java/soaprmi/soap/soaprmi/soap/SoapDeserializeContextImpl.java
HTH,
alek
>What does WS-I say about supporting href, multiRef ?
>
>---
>Susantha.
>
>-----Original Message-----
>From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
>Sent: Tuesday, May 04, 2004 2:09 PM
>To: Apache AXIS C Developers List
>Subject: Re: HTTP chunked problem
>
>
>
>
>
>The code cannot deal with href's at the moment.
>We would like href's soon and we are working on a way to find out how to
>do
>this.
>
>
>John Hawkins,
>
>
>
>
>
> "cheng liang"
>
> <chengliang2004@h
>
> otmail.com>
>To
> axis-c-dev@ws.apache.org
>
> 03/05/2004 00:51
>cc
>
>
>
>Subject
> Please respond to Re: HTTP chunked problem
>
> "Apache AXIS C
>
> Developers List"
>
>
>
>
>
>
>
>
>
>
>
>
>
>Hi, John,
>
>I think you should put HTTPChunking resolution code in the channel
>layer.
>This will make the httptransport code seems more consistent since the
>difference will be solved in the below layer.
>
>As for libwww, I have not used it yet. If it is strong enough, it would
>be
>a good choice.
>
>My major concern is the Class Object Deserialization problem. As I
>mentioned,
>the existing code could not deal with it correctly. The code could not
>recognize
>the "href" attribute, and treat it correctly.
>
>The payload is as follows:
>------------------------------------------------------------
><?xml version="1.0" encoding="UTF-8"?>
><soapenv:Envelope
>xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>xmlns:xsi="http://www.w3.org/2001/XMLSc
>hema-instance">
> <soapenv:Body>
> <ns1:getUserResponse
>soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/en
>coding/"
>xmlns:ns1="http://10.7.0.237:8080/SysPlatform/services/UserClass">
> <ns1:getUserReturn href="#id0"/>
> </ns1:getUserResponse>
> <multiRef id="id0" soapenc:root="0"
>soapenv:encodingStyle="http://schemas.xmls
>oap.org/soap/encoding/" xsi:type="ns2:UsersWS"
>xmlns:soapenc="http://schemas.xml
>soap.org/soap/encoding/" xmlns:ns2="urn:BeanService">
> <address xsi:type="xsd:string"></address>
> <birthday xsi:type="xsd:date">1986-01-01</birthday>
> <certificateCategory
>xsi:type="xsd:string">category</certificateCategory>
> <certificateNumber xsi:type="xsd:string"></certificateNumber>
> <collaboratorId xsi:type="xsd:int">0</collaboratorId>
> <country xsi:type="xsd:string">cn</country>
> <description xsi:type="xsd:string"></description>
> <email xsi:type="xsd:string"></email>
> <handset xsi:type="xsd:string"></handset>
> <handsetBand xsi:type="xsd:string" xsi:nil="true"/>
> <msn xsi:type="xsd:string"></msn>
> <nickName xsi:type="xsd:string">test2</nickName>
> <password xsi:type="xsd:string">111111</password>
> <postalcode xsi:type="xsd:string"></postalcode>
> <province xsi:type="xsd:string">31</province>
> <qq xsi:type="xsd:string"></qq>
> <question xsi:type="xsd:string">hello</question>
> <realName xsi:type="xsd:string"></realName>
> <registerIp xsi:type="xsd:string">10.7.0.10</registerIp>
> <registerTime
>xsi:type="xsd:dateTime">2004-04-27T19:57:17.000Z</registerTime>
>
> <result xsi:type="xsd:string"></result>
> <secondPassword xsi:type="xsd:string" xsi:nil="true"/>
> <sex xsi:type="xsd:string">0</sex>
> <telephone xsi:type="xsd:string"></telephone>
> <userId xsi:type="xsd:long">23</userId>
> <userName xsi:type="xsd:string">test2</userName>
> <website xsi:type="xsd:string"></website>
> </multiRef>
> </soapenv:Body>
></soapenv:Envelope>
>------------------------------------------------------------
>
>I use the following code in client stub:
>
>Ret = (UsersWS*)m_pCall->GetCmplxObject((void*)
>Axis_DeSerialize_UsersWS,
> (void*) Axis_Create_UsersWS,
> (void*) Axis_Delete_UsersWS,
> "return", 0);
>
>I get that Ret equal NULL.
>
>best,
>Cheng Liang
>
>
>
>
>
>
>>From: John Hawkins <HA...@uk.ibm.com>
>>Reply-To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>>To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>>CC: axis-c-dev@ws.apache.org
>>Subject: Re: HTTP chunked problem
>>Date: Fri, 30 Apr 2004 07:40:38 +0100
>>
>>
>>
>>
>>
>>Hi Cheng,
>>
>>fyi: Adrian, Fred Preston and I all work together so we answer
>>
>>
>questions
>on
>
>
>>behalf of each other :-)
>>
>>Yes, I saw the HTTP Content length problem but it doesn't appear to be
>>
>>
>used
>
>
>>in the code for now so I left it. However, we'll raise it on JIRA so it
>>
>>
>is
>
>
>>not lost.
>>
>>The HTTP Transport in general has a few issues in its logic. The
>>
>>
>underlying
>
>
>>channel object isn't as good as it could be.. We had to put in some
>>
>>
>hacky
>
>
>>looking code for the HTTPChunking fix. I think that a better resolution
>>would be to change the underlying channel object to work properly then
>>
>>
>we
>
>
>>could change the HTTPTransport to look nicer. But, we needed a fix
>>
>>
>quickly
>
>
>>so we didn't do this. Again we will raise a JIRA bug report to not lose
>>
>>
>it.
>
>
>>In General - I thought that there was discussion around removing the
>>HTTPTransport layer and replacing it with libwww? I think that this
>>
>>
>would
>
>
>>be a really good idea. We get so much for free with that library. It is
>>nice and modular and seems to not have had any new fixes for over two
>>
>>
>years
>
>
>>which (I think) shows how stable it must be.
>>
>>What does the dev community think to this?
>>
>>
>>
>>
>>John Hawkins,
>>
>>
>>
>>
>> "cheng liang"
>> <chengliang2004@h
>> otmail.com>
>>
>>
>To
>
>
>> axis-c-dev@ws.apache.org
>> 30/04/2004 04:28
>>
>>
>cc
>
>
>>
>>
>Subject
>
>
>> Please respond to Re: HTTP chunked problem
>> "Apache AXIS C
>> Developers List"
>>
>>
>>
>>
>>
>>
>>
>>
>>hi, Adrian Dick,
>>
>>Thanks.
>>
>>I used this code and it work fine on windows.
>>
>>But I want to point that in the following code in httptransport.cpp:
>>
>>if((pos = strLine.find("Content-Length:")) !=
>> std::string::npos)
>>{
>> m_intBodyLength = atoi(strLine.substr
>> (pos + strlen("Content-Length: ")).c_str());
>>}
>>
>>there is some exception.
>>
>>The message got from the server (apache+axis(java)+tomcat) does not
>>
>>
>contain
>
>
>>the
>>code "Content-Length:".
>>
>>The http header is as follows:
>>
>>-------------------------------------------------------------
>>HTTP/1.1 200 OK
>>Content-Type: text/xml;charset=utf-8
>>Transfer-Encoding: chunked
>>Date: Fri, 30 Apr 2004 03:06:52 GMT
>>Server: Apache-Coyote/1.1
>>-------------------------------------------------------------
>>
>>
>
>_________________________________________________________________
>享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
>
>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
href - multiRef support - [WAS]RE: HTTP chunked problem
Posted by Susantha Kumara <su...@opensource.lk>.
> -----Original Message-----
> From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
> Sent: Friday, May 07, 2004 10:12 AM
> To: Apache AXIS C Developers List
> Subject: Re: HTTP chunked problem
>
> Susantha Kumara wrote:
>
> >Yes this is the best way to do this. So in this way still the SOAP
> >stream is parsed only once ? .
> >
> yes
>
> >I mean
> ><multiRef ..>
> ></multiRef>
> >part ?
> >
> >
> yes - when parsed it is put in a hash map {id -> object ref} so href
> with that id can be resolved
>
> >Then one object of that type is created and populated.
> >
> >
> >
> of what type?
What ever type given in <multiRef ..> ... </multiRef>.
type ns2:UsersWS in this the SOAP message in this mail.
>
> >Then after the whole stream is parsed this FixUpHrefs(...) method is
> >called from either stub (at client side) and wrapper (at server
side).
> >This FixUpHrefs(..) method will clone
> >
> why clone?
If there are more than one href s refering to the same id, we may have
to clone the object. But if the object is considered read-only we can
point to the same object from different places (say parameters or array
elements). But we have to handle memory management in a bit difficult
way (may need reference counting kind of mechanism).
>
> >that object if needed and populate
> >the registered pointers. Following is some rough code that I thought
in
> >server side wrapper (modified echoStruct wrapper method from
interopbase
> >sample),
> >
> >char* pcHrefId = 0;
> >SOAPStruct *v0 =
>
>(SOAPStruct*)pIWSDZ->GetCmplxObject((void*)Axis_DeSerialize_SOAPStruct
> > , (void*)Axis_Create_SOAPStruct,
> >(void*)Axis_Delete_SOAPStruct
> > , "inputStruct", Axis_URI_SOAPStruct, &pcHrefId);
> >
> >
> why Delete is called?
No just passing the function pointer to the class's delete function.
>
> >if (!v0 && pcHrefId) /*the SOAP stream uses href */
> >{
> > pIWSDZ->RegisterPointerForHrefResolution(pcHrefId , &v0); /*
> >will be kept in Axis Engine to be populated when multiRef is parsed
and
> >FixUpHrefs is called */
> >}
> >...
> >...
> >
> >
>
> >/* Call FixUpHrefs finally */
> >pIWSDZ-> FixUpHrefs();
> >if (!v0 || !v1 ...) /* need to verify whether the pointers are
populated
> >or not */
> >{
> > return AXIS_FAIL;
> >}
> >SOAPStruct* ret = pWs->echoStruct(v0); /*Actual web service method
call
> >*/
> >
> >
> >This will need improvements in AxisEngine code as well as code
> >generation tool (WSDL2Ws tool). WSDL2Ws tool improvements will
probably
> >include.
> >1. Changes to the wrappers and stubs as above.
> >2. Some new functions to facilitate cloning of objects
> >
> >
> i do not know enough about AXIS C++ internals but as long as it is two
> phased it should work fine and be efficient - first parse whole stream
> and record any forward hrefs that needs to be resolved and in second
> phase fixup them
>
> alek
>
> >-----Original Message-----
> >From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
> >Sent: Thursday, May 06, 2004 11:11 AM
> >To: Apache AXIS C Developers List
> >Subject: Re: HTTP chunked problem
> >
> >Susantha Kumara wrote:
> >
> >
> >
> >>According to the XML-Pull base architecture of Axis C++ its
difficult
> >>
> >>
> >to
> >
> >
> >>support href. May need some architecture changes which will probably
> >>affect performance.
> >>
> >>
> >>
> >>
> >it is doable to support hrefs *and* do it in efficient manner:
> >
> >you need to record list of unresolved forward href pointers (such as
> >slots in arrays)
> >and after deserialzing whole message fill in missing slots with
actual C
> >pointers.
> >
> >i have implemented such code in Java and i believe it is doable to
port
> >the algorithm to C++ see:
> >in ArrayDeserializer when code sees href that is not yet resolved
> >(dctx.hasId(hid) == null)
> >it will record that this array slot (with index i) needs to be filled
> >when pointer to value
> >for hrefed object is available (calls dctx.addArrayFixup(o, i,
kompType,
> >hid) to record it)
> >
> > href = stag.getAttributeValueFromRawName("href");
> > if(href != null) {
> > String hid = href.substring(1); // skip # int
> >'#id1'
> > if(dctx.hasId(hid)) {
> > Object val = dctx.getIdValue(hid);
> > Array.set(o, i, val);
> > } else {
> > dctx.addArrayFixup(o, i, kompType, hid);
> > }
> > if(pp.next() != XmlPullParser.END_TAG) //skip
> >END_TAG
> > throw new DeserializeException(
> > "expected immediate end tag for href
> >element"+pp.getPosDesc());
> > } else {
> > Object val = enc.readObject(dctx, kompType,
pp,
> >stag);
> > Array.set(o, i, val);
> > }
> >
>
>http://www.extreme.indiana.edu/viewcvs/~checkout~/xsoap-java/src/java/s
o
> >aprmi/soap/soaprmi/soapenc/ArrayDeserializer.java
> >
> >deserializaiton context (dcts) dctx is in SoapDeserializeContextImpl
and
> >maintians where list of fixups (unresolved forward poiunters is kept)
> >- see in particular hasId/getIdValue, addStruct/ArrayFixuo(), and
> >fixup() methods in
>
>http://www.extreme.indiana.edu/viewcvs/~checkout~/xsoap-java/src/java/s
o
> >aprmi/soap/soaprmi/soap/SoapDeserializeContextImpl.java
> >
> >HTH,
> >
> >alek
> >
> >
> >
> >>What does WS-I say about supporting href, multiRef ?
> >>
> >>---
> >>Susantha.
> >>
> >>-----Original Message-----
> >>From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
> >>Sent: Tuesday, May 04, 2004 2:09 PM
> >>To: Apache AXIS C Developers List
> >>Subject: Re: HTTP chunked problem
> >>
> >>
> >>
> >>
> >>
> >>The code cannot deal with href's at the moment.
> >>We would like href's soon and we are working on a way to find out
how
> >>
> >>
> >to
> >
> >
> >>do
> >>this.
> >>
> >>
> >>John Hawkins,
> >>
> >>
> >>
> >>
> >>
> >> "cheng liang"
> >>
> >> <chengliang2004@h
> >>
> >> otmail.com>
> >>To
> >> axis-c-dev@ws.apache.org
> >>
> >> 03/05/2004 00:51
> >>cc
> >>
> >>
> >>
> >>Subject
> >> Please respond to Re: HTTP chunked problem
> >>
> >> "Apache AXIS C
> >>
> >> Developers List"
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>Hi, John,
> >>
> >>I think you should put HTTPChunking resolution code in the channel
> >>layer.
> >>This will make the httptransport code seems more consistent since
the
> >>difference will be solved in the below layer.
> >>
> >>As for libwww, I have not used it yet. If it is strong enough, it
would
> >>be
> >>a good choice.
> >>
> >>My major concern is the Class Object Deserialization problem. As I
> >>mentioned,
> >>the existing code could not deal with it correctly. The code could
not
> >>recognize
> >>the "href" attribute, and treat it correctly.
> >>
> >>The payload is as follows:
> >>------------------------------------------------------------
> >><?xml version="1.0" encoding="UTF-8"?>
> >><soapenv:Envelope
> >>xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> >>xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> >>xmlns:xsi="http://www.w3.org/2001/XMLSc
> >>hema-instance">
> >> <soapenv:Body>
> >> <ns1:getUserResponse
> >>soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/en
> >>coding/"
> >>xmlns:ns1="http://10.7.0.237:8080/SysPlatform/services/UserClass">
> >> <ns1:getUserReturn href="#id0"/>
> >> </ns1:getUserResponse>
> >> <multiRef id="id0" soapenc:root="0"
> >>soapenv:encodingStyle="http://schemas.xmls
> >>oap.org/soap/encoding/" xsi:type="ns2:UsersWS"
> >>xmlns:soapenc="http://schemas.xml
> >>soap.org/soap/encoding/" xmlns:ns2="urn:BeanService">
> >> <address xsi:type="xsd:string"></address>
> >> <birthday xsi:type="xsd:date">1986-01-01</birthday>
> >> <certificateCategory
> >>xsi:type="xsd:string">category</certificateCategory>
> >> <certificateNumber xsi:type="xsd:string"></certificateNumber>
> >> <collaboratorId xsi:type="xsd:int">0</collaboratorId>
> >> <country xsi:type="xsd:string">cn</country>
> >> <description xsi:type="xsd:string"></description>
> >> <email xsi:type="xsd:string"></email>
> >> <handset xsi:type="xsd:string"></handset>
> >> <handsetBand xsi:type="xsd:string" xsi:nil="true"/>
> >> <msn xsi:type="xsd:string"></msn>
> >> <nickName xsi:type="xsd:string">test2</nickName>
> >> <password xsi:type="xsd:string">111111</password>
> >> <postalcode xsi:type="xsd:string"></postalcode>
> >> <province xsi:type="xsd:string">31</province>
> >> <qq xsi:type="xsd:string"></qq>
> >> <question xsi:type="xsd:string">hello</question>
> >> <realName xsi:type="xsd:string"></realName>
> >> <registerIp xsi:type="xsd:string">10.7.0.10</registerIp>
> >> <registerTime
> >>xsi:type="xsd:dateTime">2004-04-27T19:57:17.000Z</registerTime>
> >>
> >> <result xsi:type="xsd:string"></result>
> >> <secondPassword xsi:type="xsd:string" xsi:nil="true"/>
> >> <sex xsi:type="xsd:string">0</sex>
> >> <telephone xsi:type="xsd:string"></telephone>
> >> <userId xsi:type="xsd:long">23</userId>
> >> <userName xsi:type="xsd:string">test2</userName>
> >> <website xsi:type="xsd:string"></website>
> >> </multiRef>
> >> </soapenv:Body>
> >></soapenv:Envelope>
> >>------------------------------------------------------------
> >>
> >>I use the following code in client stub:
> >>
> >>Ret = (UsersWS*)m_pCall->GetCmplxObject((void*)
> >>Axis_DeSerialize_UsersWS,
> >> (void*) Axis_Create_UsersWS,
> >> (void*) Axis_Delete_UsersWS,
> >> "return", 0);
> >>
> >>I get that Ret equal NULL.
> >>
> >>best,
> >>Cheng Liang
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>>From: John Hawkins <HA...@uk.ibm.com>
> >>>Reply-To: "Apache AXIS C Developers List"
<ax...@ws.apache.org>
> >>>To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
> >>>CC: axis-c-dev@ws.apache.org
> >>>Subject: Re: HTTP chunked problem
> >>>Date: Fri, 30 Apr 2004 07:40:38 +0100
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>Hi Cheng,
> >>>
> >>>fyi: Adrian, Fred Preston and I all work together so we answer
> >>>
> >>>
> >>>
> >>>
> >>questions
> >>on
> >>
> >>
> >>
> >>
> >>>behalf of each other :-)
> >>>
> >>>Yes, I saw the HTTP Content length problem but it doesn't appear to
be
> >>>
> >>>
> >>>
> >>>
> >>used
> >>
> >>
> >>
> >>
> >>>in the code for now so I left it. However, we'll raise it on JIRA
so
> >>>
> >>>
> >it
> >
> >
> >>>
> >>>
> >>>
> >>>
> >>is
> >>
> >>
> >>
> >>
> >>>not lost.
> >>>
> >>>The HTTP Transport in general has a few issues in its logic. The
> >>>
> >>>
> >>>
> >>>
> >>underlying
> >>
> >>
> >>
> >>
> >>>channel object isn't as good as it could be.. We had to put in some
> >>>
> >>>
> >>>
> >>>
> >>hacky
> >>
> >>
> >>
> >>
> >>>looking code for the HTTPChunking fix. I think that a better
> >>>
> >>>
> >resolution
> >
> >
> >>>would be to change the underlying channel object to work properly
then
> >>>
> >>>
> >>>
> >>>
> >>we
> >>
> >>
> >>
> >>
> >>>could change the HTTPTransport to look nicer. But, we needed a fix
> >>>
> >>>
> >>>
> >>>
> >>quickly
> >>
> >>
> >>
> >>
> >>>so we didn't do this. Again we will raise a JIRA bug report to not
> >>>
> >>>
> >lose
> >
> >
> >>>
> >>>
> >>>
> >>>
> >>it.
> >>
> >>
> >>
> >>
> >>>In General - I thought that there was discussion around removing
the
> >>>HTTPTransport layer and replacing it with libwww? I think that this
> >>>
> >>>
> >>>
> >>>
> >>would
> >>
> >>
> >>
> >>
> >>>be a really good idea. We get so much for free with that library.
It
> >>>
> >>>
> >is
> >
> >
> >>>nice and modular and seems to not have had any new fixes for over
two
> >>>
> >>>
> >>>
> >>>
> >>years
> >>
> >>
> >>
> >>
> >>>which (I think) shows how stable it must be.
> >>>
> >>>What does the dev community think to this?
> >>>
> >>>
> >>>
> >>>
> >>>John Hawkins,
> >>>
> >>>
> >>>
> >>>
> >>> "cheng liang"
> >>> <chengliang2004@h
> >>> otmail.com>
> >>>
> >>>
> >>>
> >>>
> >>To
> >>
> >>
> >>
> >>
> >>> axis-c-dev@ws.apache.org
> >>> 30/04/2004 04:28
> >>>
> >>>
> >>>
> >>>
> >>cc
> >>
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >>>
> >>Subject
> >>
> >>
> >>
> >>
> >>> Please respond to Re: HTTP chunked problem
> >>> "Apache AXIS C
> >>> Developers List"
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>hi, Adrian Dick,
> >>>
> >>>Thanks.
> >>>
> >>>I used this code and it work fine on windows.
> >>>
> >>>But I want to point that in the following code in
httptransport.cpp:
> >>>
> >>>if((pos = strLine.find("Content-Length:")) !=
> >>> std::string::npos)
> >>>{
> >>> m_intBodyLength = atoi(strLine.substr
> >>> (pos + strlen("Content-Length: ")).c_str());
> >>>}
> >>>
> >>>there is some exception.
> >>>
> >>>The message got from the server (apache+axis(java)+tomcat) does not
> >>>
> >>>
> >>>
> >>>
> >>contain
> >>
> >>
> >>
> >>
> >>>the
> >>>code "Content-Length:".
> >>>
> >>>The http header is as follows:
> >>>
> >>>-------------------------------------------------------------
> >>>HTTP/1.1 200 OK
> >>>Content-Type: text/xml;charset=utf-8
> >>>Transfer-Encoding: chunked
> >>>Date: Fri, 30 Apr 2004 03:06:52 GMT
> >>>Server: Apache-Coyote/1.1
> >>>-------------------------------------------------------------
> >>>
> >>>
> >>>
> >>>
> >>_________________________________________________________________
> >>享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
> --
> The best way to predict the future is to invent it - Alan Kay
Re: HTTP chunked problem
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Susantha Kumara wrote:
>Yes this is the best way to do this. So in this way still the SOAP
>stream is parsed only once ? .
>
yes
>I mean
><multiRef ..>
></multiRef>
>part ?
>
>
yes - when parsed it is put in a hash map {id -> object ref} so href
with that id can be resolved
>Then one object of that type is created and populated.
>
>
>
of what type?
>Then after the whole stream is parsed this FixUpHrefs(...) method is
>called from either stub (at client side) and wrapper (at server side).
>This FixUpHrefs(..) method will clone
>
why clone?
>that object if needed and populate
>the registered pointers. Following is some rough code that I thought in
>server side wrapper (modified echoStruct wrapper method from interopbase
>sample),
>
>char* pcHrefId = 0;
>SOAPStruct *v0 =
>(SOAPStruct*)pIWSDZ->GetCmplxObject((void*)Axis_DeSerialize_SOAPStruct
> , (void*)Axis_Create_SOAPStruct,
>(void*)Axis_Delete_SOAPStruct
> , "inputStruct", Axis_URI_SOAPStruct, &pcHrefId);
>
>
why Delete is called?
>if (!v0 && pcHrefId) /*the SOAP stream uses href */
>{
> pIWSDZ->RegisterPointerForHrefResolution(pcHrefId , &v0); /*
>will be kept in Axis Engine to be populated when multiRef is parsed and
>FixUpHrefs is called */
>}
>...
>...
>
>
>/* Call FixUpHrefs finally */
>pIWSDZ-> FixUpHrefs();
>if (!v0 || !v1 ...) /* need to verify whether the pointers are populated
>or not */
>{
> return AXIS_FAIL;
>}
>SOAPStruct* ret = pWs->echoStruct(v0); /*Actual web service method call
>*/
>
>
>This will need improvements in AxisEngine code as well as code
>generation tool (WSDL2Ws tool). WSDL2Ws tool improvements will probably
>include.
>1. Changes to the wrappers and stubs as above.
>2. Some new functions to facilitate cloning of objects
>
>
i do not know enough about AXIS C++ internals but as long as it is two
phased it should work fine and be efficient - first parse whole stream
and record any forward hrefs that needs to be resolved and in second
phase fixup them
alek
>-----Original Message-----
>From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
>Sent: Thursday, May 06, 2004 11:11 AM
>To: Apache AXIS C Developers List
>Subject: Re: HTTP chunked problem
>
>Susantha Kumara wrote:
>
>
>
>>According to the XML-Pull base architecture of Axis C++ its difficult
>>
>>
>to
>
>
>>support href. May need some architecture changes which will probably
>>affect performance.
>>
>>
>>
>>
>it is doable to support hrefs *and* do it in efficient manner:
>
>you need to record list of unresolved forward href pointers (such as
>slots in arrays)
>and after deserialzing whole message fill in missing slots with actual C
>pointers.
>
>i have implemented such code in Java and i believe it is doable to port
>the algorithm to C++ see:
>in ArrayDeserializer when code sees href that is not yet resolved
>(dctx.hasId(hid) == null)
>it will record that this array slot (with index i) needs to be filled
>when pointer to value
>for hrefed object is available (calls dctx.addArrayFixup(o, i, kompType,
>hid) to record it)
>
> href = stag.getAttributeValueFromRawName("href");
> if(href != null) {
> String hid = href.substring(1); // skip # int
>'#id1'
> if(dctx.hasId(hid)) {
> Object val = dctx.getIdValue(hid);
> Array.set(o, i, val);
> } else {
> dctx.addArrayFixup(o, i, kompType, hid);
> }
> if(pp.next() != XmlPullParser.END_TAG) //skip
>END_TAG
> throw new DeserializeException(
> "expected immediate end tag for href
>element"+pp.getPosDesc());
> } else {
> Object val = enc.readObject(dctx, kompType, pp,
>stag);
> Array.set(o, i, val);
> }
>
>http://www.extreme.indiana.edu/viewcvs/~checkout~/xsoap-java/src/java/so
>aprmi/soap/soaprmi/soapenc/ArrayDeserializer.java
>
>deserializaiton context (dcts) dctx is in SoapDeserializeContextImpl and
>maintians where list of fixups (unresolved forward poiunters is kept)
>- see in particular hasId/getIdValue, addStruct/ArrayFixuo(), and
>fixup() methods in
>http://www.extreme.indiana.edu/viewcvs/~checkout~/xsoap-java/src/java/so
>aprmi/soap/soaprmi/soap/SoapDeserializeContextImpl.java
>
>HTH,
>
>alek
>
>
>
>>What does WS-I say about supporting href, multiRef ?
>>
>>---
>>Susantha.
>>
>>-----Original Message-----
>>From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
>>Sent: Tuesday, May 04, 2004 2:09 PM
>>To: Apache AXIS C Developers List
>>Subject: Re: HTTP chunked problem
>>
>>
>>
>>
>>
>>The code cannot deal with href's at the moment.
>>We would like href's soon and we are working on a way to find out how
>>
>>
>to
>
>
>>do
>>this.
>>
>>
>>John Hawkins,
>>
>>
>>
>>
>>
>> "cheng liang"
>>
>> <chengliang2004@h
>>
>> otmail.com>
>>To
>> axis-c-dev@ws.apache.org
>>
>> 03/05/2004 00:51
>>cc
>>
>>
>>
>>Subject
>> Please respond to Re: HTTP chunked problem
>>
>> "Apache AXIS C
>>
>> Developers List"
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>Hi, John,
>>
>>I think you should put HTTPChunking resolution code in the channel
>>layer.
>>This will make the httptransport code seems more consistent since the
>>difference will be solved in the below layer.
>>
>>As for libwww, I have not used it yet. If it is strong enough, it would
>>be
>>a good choice.
>>
>>My major concern is the Class Object Deserialization problem. As I
>>mentioned,
>>the existing code could not deal with it correctly. The code could not
>>recognize
>>the "href" attribute, and treat it correctly.
>>
>>The payload is as follows:
>>------------------------------------------------------------
>><?xml version="1.0" encoding="UTF-8"?>
>><soapenv:Envelope
>>xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>>xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>>xmlns:xsi="http://www.w3.org/2001/XMLSc
>>hema-instance">
>> <soapenv:Body>
>> <ns1:getUserResponse
>>soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/en
>>coding/"
>>xmlns:ns1="http://10.7.0.237:8080/SysPlatform/services/UserClass">
>> <ns1:getUserReturn href="#id0"/>
>> </ns1:getUserResponse>
>> <multiRef id="id0" soapenc:root="0"
>>soapenv:encodingStyle="http://schemas.xmls
>>oap.org/soap/encoding/" xsi:type="ns2:UsersWS"
>>xmlns:soapenc="http://schemas.xml
>>soap.org/soap/encoding/" xmlns:ns2="urn:BeanService">
>> <address xsi:type="xsd:string"></address>
>> <birthday xsi:type="xsd:date">1986-01-01</birthday>
>> <certificateCategory
>>xsi:type="xsd:string">category</certificateCategory>
>> <certificateNumber xsi:type="xsd:string"></certificateNumber>
>> <collaboratorId xsi:type="xsd:int">0</collaboratorId>
>> <country xsi:type="xsd:string">cn</country>
>> <description xsi:type="xsd:string"></description>
>> <email xsi:type="xsd:string"></email>
>> <handset xsi:type="xsd:string"></handset>
>> <handsetBand xsi:type="xsd:string" xsi:nil="true"/>
>> <msn xsi:type="xsd:string"></msn>
>> <nickName xsi:type="xsd:string">test2</nickName>
>> <password xsi:type="xsd:string">111111</password>
>> <postalcode xsi:type="xsd:string"></postalcode>
>> <province xsi:type="xsd:string">31</province>
>> <qq xsi:type="xsd:string"></qq>
>> <question xsi:type="xsd:string">hello</question>
>> <realName xsi:type="xsd:string"></realName>
>> <registerIp xsi:type="xsd:string">10.7.0.10</registerIp>
>> <registerTime
>>xsi:type="xsd:dateTime">2004-04-27T19:57:17.000Z</registerTime>
>>
>> <result xsi:type="xsd:string"></result>
>> <secondPassword xsi:type="xsd:string" xsi:nil="true"/>
>> <sex xsi:type="xsd:string">0</sex>
>> <telephone xsi:type="xsd:string"></telephone>
>> <userId xsi:type="xsd:long">23</userId>
>> <userName xsi:type="xsd:string">test2</userName>
>> <website xsi:type="xsd:string"></website>
>> </multiRef>
>> </soapenv:Body>
>></soapenv:Envelope>
>>------------------------------------------------------------
>>
>>I use the following code in client stub:
>>
>>Ret = (UsersWS*)m_pCall->GetCmplxObject((void*)
>>Axis_DeSerialize_UsersWS,
>> (void*) Axis_Create_UsersWS,
>> (void*) Axis_Delete_UsersWS,
>> "return", 0);
>>
>>I get that Ret equal NULL.
>>
>>best,
>>Cheng Liang
>>
>>
>>
>>
>>
>>
>>
>>
>>>From: John Hawkins <HA...@uk.ibm.com>
>>>Reply-To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>>>To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>>>CC: axis-c-dev@ws.apache.org
>>>Subject: Re: HTTP chunked problem
>>>Date: Fri, 30 Apr 2004 07:40:38 +0100
>>>
>>>
>>>
>>>
>>>
>>>Hi Cheng,
>>>
>>>fyi: Adrian, Fred Preston and I all work together so we answer
>>>
>>>
>>>
>>>
>>questions
>>on
>>
>>
>>
>>
>>>behalf of each other :-)
>>>
>>>Yes, I saw the HTTP Content length problem but it doesn't appear to be
>>>
>>>
>>>
>>>
>>used
>>
>>
>>
>>
>>>in the code for now so I left it. However, we'll raise it on JIRA so
>>>
>>>
>it
>
>
>>>
>>>
>>>
>>>
>>is
>>
>>
>>
>>
>>>not lost.
>>>
>>>The HTTP Transport in general has a few issues in its logic. The
>>>
>>>
>>>
>>>
>>underlying
>>
>>
>>
>>
>>>channel object isn't as good as it could be.. We had to put in some
>>>
>>>
>>>
>>>
>>hacky
>>
>>
>>
>>
>>>looking code for the HTTPChunking fix. I think that a better
>>>
>>>
>resolution
>
>
>>>would be to change the underlying channel object to work properly then
>>>
>>>
>>>
>>>
>>we
>>
>>
>>
>>
>>>could change the HTTPTransport to look nicer. But, we needed a fix
>>>
>>>
>>>
>>>
>>quickly
>>
>>
>>
>>
>>>so we didn't do this. Again we will raise a JIRA bug report to not
>>>
>>>
>lose
>
>
>>>
>>>
>>>
>>>
>>it.
>>
>>
>>
>>
>>>In General - I thought that there was discussion around removing the
>>>HTTPTransport layer and replacing it with libwww? I think that this
>>>
>>>
>>>
>>>
>>would
>>
>>
>>
>>
>>>be a really good idea. We get so much for free with that library. It
>>>
>>>
>is
>
>
>>>nice and modular and seems to not have had any new fixes for over two
>>>
>>>
>>>
>>>
>>years
>>
>>
>>
>>
>>>which (I think) shows how stable it must be.
>>>
>>>What does the dev community think to this?
>>>
>>>
>>>
>>>
>>>John Hawkins,
>>>
>>>
>>>
>>>
>>> "cheng liang"
>>> <chengliang2004@h
>>> otmail.com>
>>>
>>>
>>>
>>>
>>To
>>
>>
>>
>>
>>> axis-c-dev@ws.apache.org
>>> 30/04/2004 04:28
>>>
>>>
>>>
>>>
>>cc
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>Subject
>>
>>
>>
>>
>>> Please respond to Re: HTTP chunked problem
>>> "Apache AXIS C
>>> Developers List"
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>hi, Adrian Dick,
>>>
>>>Thanks.
>>>
>>>I used this code and it work fine on windows.
>>>
>>>But I want to point that in the following code in httptransport.cpp:
>>>
>>>if((pos = strLine.find("Content-Length:")) !=
>>> std::string::npos)
>>>{
>>> m_intBodyLength = atoi(strLine.substr
>>> (pos + strlen("Content-Length: ")).c_str());
>>>}
>>>
>>>there is some exception.
>>>
>>>The message got from the server (apache+axis(java)+tomcat) does not
>>>
>>>
>>>
>>>
>>contain
>>
>>
>>
>>
>>>the
>>>code "Content-Length:".
>>>
>>>The http header is as follows:
>>>
>>>-------------------------------------------------------------
>>>HTTP/1.1 200 OK
>>>Content-Type: text/xml;charset=utf-8
>>>Transfer-Encoding: chunked
>>>Date: Fri, 30 Apr 2004 03:06:52 GMT
>>>Server: Apache-Coyote/1.1
>>>-------------------------------------------------------------
>>>
>>>
>>>
>>>
>>_________________________________________________________________
>>享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
RE: HTTP chunked problem
Posted by Susantha Kumara <su...@opensource.lk>.
Yes this is the best way to do this. So in this way still the SOAP
stream is parsed only once ? . I mean
<multiRef ..>
</multiRef>
part ?
Then one object of that type is created and populated.
Then after the whole stream is parsed this FixUpHrefs(...) method is
called from either stub (at client side) and wrapper (at server side).
This FixUpHrefs(..) method will clone that object if needed and populate
the registered pointers. Following is some rough code that I thought in
server side wrapper (modified echoStruct wrapper method from interopbase
sample),
char* pcHrefId = 0;
SOAPStruct *v0 =
(SOAPStruct*)pIWSDZ->GetCmplxObject((void*)Axis_DeSerialize_SOAPStruct
, (void*)Axis_Create_SOAPStruct,
(void*)Axis_Delete_SOAPStruct
, "inputStruct", Axis_URI_SOAPStruct, &pcHrefId);
if (!v0 && pcHrefId) /*the SOAP stream uses href */
{
pIWSDZ->RegisterPointerForHrefResolution(pcHrefId , &v0); /*
will be kept in Axis Engine to be populated when multiRef is parsed and
FixUpHrefs is called */
}
...
...
/* Call FixUpHrefs finally */
pIWSDZ-> FixUpHrefs();
if (!v0 || !v1 ...) /* need to verify whether the pointers are populated
or not */
{
return AXIS_FAIL;
}
SOAPStruct* ret = pWs->echoStruct(v0); /*Actual web service method call
*/
This will need improvements in AxisEngine code as well as code
generation tool (WSDL2Ws tool). WSDL2Ws tool improvements will probably
include.
1. Changes to the wrappers and stubs as above.
2. Some new functions to facilitate cloning of objects
---
Susantha
-----Original Message-----
From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
Sent: Thursday, May 06, 2004 11:11 AM
To: Apache AXIS C Developers List
Subject: Re: HTTP chunked problem
Susantha Kumara wrote:
>According to the XML-Pull base architecture of Axis C++ its difficult
to
>support href. May need some architecture changes which will probably
>affect performance.
>
>
it is doable to support hrefs *and* do it in efficient manner:
you need to record list of unresolved forward href pointers (such as
slots in arrays)
and after deserialzing whole message fill in missing slots with actual C
pointers.
i have implemented such code in Java and i believe it is doable to port
the algorithm to C++ see:
in ArrayDeserializer when code sees href that is not yet resolved
(dctx.hasId(hid) == null)
it will record that this array slot (with index i) needs to be filled
when pointer to value
for hrefed object is available (calls dctx.addArrayFixup(o, i, kompType,
hid) to record it)
href = stag.getAttributeValueFromRawName("href");
if(href != null) {
String hid = href.substring(1); // skip # int
'#id1'
if(dctx.hasId(hid)) {
Object val = dctx.getIdValue(hid);
Array.set(o, i, val);
} else {
dctx.addArrayFixup(o, i, kompType, hid);
}
if(pp.next() != XmlPullParser.END_TAG) //skip
END_TAG
throw new DeserializeException(
"expected immediate end tag for href
element"+pp.getPosDesc());
} else {
Object val = enc.readObject(dctx, kompType, pp,
stag);
Array.set(o, i, val);
}
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsoap-java/src/java/so
aprmi/soap/soaprmi/soapenc/ArrayDeserializer.java
deserializaiton context (dcts) dctx is in SoapDeserializeContextImpl and
maintians where list of fixups (unresolved forward poiunters is kept)
- see in particular hasId/getIdValue, addStruct/ArrayFixuo(), and
fixup() methods in
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsoap-java/src/java/so
aprmi/soap/soaprmi/soap/SoapDeserializeContextImpl.java
HTH,
alek
>What does WS-I say about supporting href, multiRef ?
>
>---
>Susantha.
>
>-----Original Message-----
>From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
>Sent: Tuesday, May 04, 2004 2:09 PM
>To: Apache AXIS C Developers List
>Subject: Re: HTTP chunked problem
>
>
>
>
>
>The code cannot deal with href's at the moment.
>We would like href's soon and we are working on a way to find out how
to
>do
>this.
>
>
>John Hawkins,
>
>
>
>
>
> "cheng liang"
>
> <chengliang2004@h
>
> otmail.com>
>To
> axis-c-dev@ws.apache.org
>
> 03/05/2004 00:51
>cc
>
>
>
>Subject
> Please respond to Re: HTTP chunked problem
>
> "Apache AXIS C
>
> Developers List"
>
>
>
>
>
>
>
>
>
>
>
>
>
>Hi, John,
>
>I think you should put HTTPChunking resolution code in the channel
>layer.
>This will make the httptransport code seems more consistent since the
>difference will be solved in the below layer.
>
>As for libwww, I have not used it yet. If it is strong enough, it would
>be
>a good choice.
>
>My major concern is the Class Object Deserialization problem. As I
>mentioned,
>the existing code could not deal with it correctly. The code could not
>recognize
>the "href" attribute, and treat it correctly.
>
>The payload is as follows:
>------------------------------------------------------------
><?xml version="1.0" encoding="UTF-8"?>
><soapenv:Envelope
>xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>xmlns:xsi="http://www.w3.org/2001/XMLSc
>hema-instance">
> <soapenv:Body>
> <ns1:getUserResponse
>soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/en
>coding/"
>xmlns:ns1="http://10.7.0.237:8080/SysPlatform/services/UserClass">
> <ns1:getUserReturn href="#id0"/>
> </ns1:getUserResponse>
> <multiRef id="id0" soapenc:root="0"
>soapenv:encodingStyle="http://schemas.xmls
>oap.org/soap/encoding/" xsi:type="ns2:UsersWS"
>xmlns:soapenc="http://schemas.xml
>soap.org/soap/encoding/" xmlns:ns2="urn:BeanService">
> <address xsi:type="xsd:string"></address>
> <birthday xsi:type="xsd:date">1986-01-01</birthday>
> <certificateCategory
>xsi:type="xsd:string">category</certificateCategory>
> <certificateNumber xsi:type="xsd:string"></certificateNumber>
> <collaboratorId xsi:type="xsd:int">0</collaboratorId>
> <country xsi:type="xsd:string">cn</country>
> <description xsi:type="xsd:string"></description>
> <email xsi:type="xsd:string"></email>
> <handset xsi:type="xsd:string"></handset>
> <handsetBand xsi:type="xsd:string" xsi:nil="true"/>
> <msn xsi:type="xsd:string"></msn>
> <nickName xsi:type="xsd:string">test2</nickName>
> <password xsi:type="xsd:string">111111</password>
> <postalcode xsi:type="xsd:string"></postalcode>
> <province xsi:type="xsd:string">31</province>
> <qq xsi:type="xsd:string"></qq>
> <question xsi:type="xsd:string">hello</question>
> <realName xsi:type="xsd:string"></realName>
> <registerIp xsi:type="xsd:string">10.7.0.10</registerIp>
> <registerTime
>xsi:type="xsd:dateTime">2004-04-27T19:57:17.000Z</registerTime>
>
> <result xsi:type="xsd:string"></result>
> <secondPassword xsi:type="xsd:string" xsi:nil="true"/>
> <sex xsi:type="xsd:string">0</sex>
> <telephone xsi:type="xsd:string"></telephone>
> <userId xsi:type="xsd:long">23</userId>
> <userName xsi:type="xsd:string">test2</userName>
> <website xsi:type="xsd:string"></website>
> </multiRef>
> </soapenv:Body>
></soapenv:Envelope>
>------------------------------------------------------------
>
>I use the following code in client stub:
>
>Ret = (UsersWS*)m_pCall->GetCmplxObject((void*)
>Axis_DeSerialize_UsersWS,
> (void*) Axis_Create_UsersWS,
> (void*) Axis_Delete_UsersWS,
> "return", 0);
>
>I get that Ret equal NULL.
>
>best,
>Cheng Liang
>
>
>
>
>
>
>>From: John Hawkins <HA...@uk.ibm.com>
>>Reply-To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>>To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>>CC: axis-c-dev@ws.apache.org
>>Subject: Re: HTTP chunked problem
>>Date: Fri, 30 Apr 2004 07:40:38 +0100
>>
>>
>>
>>
>>
>>Hi Cheng,
>>
>>fyi: Adrian, Fred Preston and I all work together so we answer
>>
>>
>questions
>on
>
>
>>behalf of each other :-)
>>
>>Yes, I saw the HTTP Content length problem but it doesn't appear to be
>>
>>
>used
>
>
>>in the code for now so I left it. However, we'll raise it on JIRA so
it
>>
>>
>is
>
>
>>not lost.
>>
>>The HTTP Transport in general has a few issues in its logic. The
>>
>>
>underlying
>
>
>>channel object isn't as good as it could be.. We had to put in some
>>
>>
>hacky
>
>
>>looking code for the HTTPChunking fix. I think that a better
resolution
>>would be to change the underlying channel object to work properly then
>>
>>
>we
>
>
>>could change the HTTPTransport to look nicer. But, we needed a fix
>>
>>
>quickly
>
>
>>so we didn't do this. Again we will raise a JIRA bug report to not
lose
>>
>>
>it.
>
>
>>In General - I thought that there was discussion around removing the
>>HTTPTransport layer and replacing it with libwww? I think that this
>>
>>
>would
>
>
>>be a really good idea. We get so much for free with that library. It
is
>>nice and modular and seems to not have had any new fixes for over two
>>
>>
>years
>
>
>>which (I think) shows how stable it must be.
>>
>>What does the dev community think to this?
>>
>>
>>
>>
>>John Hawkins,
>>
>>
>>
>>
>> "cheng liang"
>> <chengliang2004@h
>> otmail.com>
>>
>>
>To
>
>
>> axis-c-dev@ws.apache.org
>> 30/04/2004 04:28
>>
>>
>cc
>
>
>>
>>
>Subject
>
>
>> Please respond to Re: HTTP chunked problem
>> "Apache AXIS C
>> Developers List"
>>
>>
>>
>>
>>
>>
>>
>>
>>hi, Adrian Dick,
>>
>>Thanks.
>>
>>I used this code and it work fine on windows.
>>
>>But I want to point that in the following code in httptransport.cpp:
>>
>>if((pos = strLine.find("Content-Length:")) !=
>> std::string::npos)
>>{
>> m_intBodyLength = atoi(strLine.substr
>> (pos + strlen("Content-Length: ")).c_str());
>>}
>>
>>there is some exception.
>>
>>The message got from the server (apache+axis(java)+tomcat) does not
>>
>>
>contain
>
>
>>the
>>code "Content-Length:".
>>
>>The http header is as follows:
>>
>>-------------------------------------------------------------
>>HTTP/1.1 200 OK
>>Content-Type: text/xml;charset=utf-8
>>Transfer-Encoding: chunked
>>Date: Fri, 30 Apr 2004 03:06:52 GMT
>>Server: Apache-Coyote/1.1
>>-------------------------------------------------------------
>>
>>
>
>_________________________________________________________________
>享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
>
>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: HTTP chunked problem
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Susantha Kumara wrote:
>According to the XML-Pull base architecture of Axis C++ its difficult to
>support href. May need some architecture changes which will probably
>affect performance.
>
>
it is doable to support hrefs *and* do it in efficient manner:
you need to record list of unresolved forward href pointers (such as
slots in arrays)
and after deserialzing whole message fill in missing slots with actual C
pointers.
i have implemented such code in Java and i believe it is doable to port
the algorithm to C++ see:
in ArrayDeserializer when code sees href that is not yet resolved
(dctx.hasId(hid) == null)
it will record that this array slot (with index i) needs to be filled
when pointer to value
for hrefed object is available (calls dctx.addArrayFixup(o, i, kompType,
hid) to record it)
href = stag.getAttributeValueFromRawName("href");
if(href != null) {
String hid = href.substring(1); // skip # int '#id1'
if(dctx.hasId(hid)) {
Object val = dctx.getIdValue(hid);
Array.set(o, i, val);
} else {
dctx.addArrayFixup(o, i, kompType, hid);
}
if(pp.next() != XmlPullParser.END_TAG) //skip END_TAG
throw new DeserializeException(
"expected immediate end tag for href element"+pp.getPosDesc());
} else {
Object val = enc.readObject(dctx, kompType, pp, stag);
Array.set(o, i, val);
}
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsoap-java/src/java/soaprmi/soap/soaprmi/soapenc/ArrayDeserializer.java
deserializaiton context (dcts) dctx is in SoapDeserializeContextImpl and
maintians where list of fixups (unresolved forward poiunters is kept)
- see in particular hasId/getIdValue, addStruct/ArrayFixuo(), and
fixup() methods in
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsoap-java/src/java/soaprmi/soap/soaprmi/soap/SoapDeserializeContextImpl.java
HTH,
alek
>What does WS-I say about supporting href, multiRef ?
>
>---
>Susantha.
>
>-----Original Message-----
>From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
>Sent: Tuesday, May 04, 2004 2:09 PM
>To: Apache AXIS C Developers List
>Subject: Re: HTTP chunked problem
>
>
>
>
>
>The code cannot deal with href's at the moment.
>We would like href's soon and we are working on a way to find out how to
>do
>this.
>
>
>John Hawkins,
>
>
>
>
>
> "cheng liang"
>
> <chengliang2004@h
>
> otmail.com>
>To
> axis-c-dev@ws.apache.org
>
> 03/05/2004 00:51
>cc
>
>
>
>Subject
> Please respond to Re: HTTP chunked problem
>
> "Apache AXIS C
>
> Developers List"
>
>
>
>
>
>
>
>
>
>
>
>
>
>Hi, John,
>
>I think you should put HTTPChunking resolution code in the channel
>layer.
>This will make the httptransport code seems more consistent since the
>difference will be solved in the below layer.
>
>As for libwww, I have not used it yet. If it is strong enough, it would
>be
>a good choice.
>
>My major concern is the Class Object Deserialization problem. As I
>mentioned,
>the existing code could not deal with it correctly. The code could not
>recognize
>the "href" attribute, and treat it correctly.
>
>The payload is as follows:
>------------------------------------------------------------
><?xml version="1.0" encoding="UTF-8"?>
><soapenv:Envelope
>xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>xmlns:xsi="http://www.w3.org/2001/XMLSc
>hema-instance">
> <soapenv:Body>
> <ns1:getUserResponse
>soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/en
>coding/"
>xmlns:ns1="http://10.7.0.237:8080/SysPlatform/services/UserClass">
> <ns1:getUserReturn href="#id0"/>
> </ns1:getUserResponse>
> <multiRef id="id0" soapenc:root="0"
>soapenv:encodingStyle="http://schemas.xmls
>oap.org/soap/encoding/" xsi:type="ns2:UsersWS"
>xmlns:soapenc="http://schemas.xml
>soap.org/soap/encoding/" xmlns:ns2="urn:BeanService">
> <address xsi:type="xsd:string"></address>
> <birthday xsi:type="xsd:date">1986-01-01</birthday>
> <certificateCategory
>xsi:type="xsd:string">category</certificateCategory>
> <certificateNumber xsi:type="xsd:string"></certificateNumber>
> <collaboratorId xsi:type="xsd:int">0</collaboratorId>
> <country xsi:type="xsd:string">cn</country>
> <description xsi:type="xsd:string"></description>
> <email xsi:type="xsd:string"></email>
> <handset xsi:type="xsd:string"></handset>
> <handsetBand xsi:type="xsd:string" xsi:nil="true"/>
> <msn xsi:type="xsd:string"></msn>
> <nickName xsi:type="xsd:string">test2</nickName>
> <password xsi:type="xsd:string">111111</password>
> <postalcode xsi:type="xsd:string"></postalcode>
> <province xsi:type="xsd:string">31</province>
> <qq xsi:type="xsd:string"></qq>
> <question xsi:type="xsd:string">hello</question>
> <realName xsi:type="xsd:string"></realName>
> <registerIp xsi:type="xsd:string">10.7.0.10</registerIp>
> <registerTime
>xsi:type="xsd:dateTime">2004-04-27T19:57:17.000Z</registerTime>
>
> <result xsi:type="xsd:string"></result>
> <secondPassword xsi:type="xsd:string" xsi:nil="true"/>
> <sex xsi:type="xsd:string">0</sex>
> <telephone xsi:type="xsd:string"></telephone>
> <userId xsi:type="xsd:long">23</userId>
> <userName xsi:type="xsd:string">test2</userName>
> <website xsi:type="xsd:string"></website>
> </multiRef>
> </soapenv:Body>
></soapenv:Envelope>
>------------------------------------------------------------
>
>I use the following code in client stub:
>
>Ret = (UsersWS*)m_pCall->GetCmplxObject((void*)
>Axis_DeSerialize_UsersWS,
> (void*) Axis_Create_UsersWS,
> (void*) Axis_Delete_UsersWS,
> "return", 0);
>
>I get that Ret equal NULL.
>
>best,
>Cheng Liang
>
>
>
>
>
>
>>From: John Hawkins <HA...@uk.ibm.com>
>>Reply-To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>>To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>>CC: axis-c-dev@ws.apache.org
>>Subject: Re: HTTP chunked problem
>>Date: Fri, 30 Apr 2004 07:40:38 +0100
>>
>>
>>
>>
>>
>>Hi Cheng,
>>
>>fyi: Adrian, Fred Preston and I all work together so we answer
>>
>>
>questions
>on
>
>
>>behalf of each other :-)
>>
>>Yes, I saw the HTTP Content length problem but it doesn't appear to be
>>
>>
>used
>
>
>>in the code for now so I left it. However, we'll raise it on JIRA so it
>>
>>
>is
>
>
>>not lost.
>>
>>The HTTP Transport in general has a few issues in its logic. The
>>
>>
>underlying
>
>
>>channel object isn't as good as it could be.. We had to put in some
>>
>>
>hacky
>
>
>>looking code for the HTTPChunking fix. I think that a better resolution
>>would be to change the underlying channel object to work properly then
>>
>>
>we
>
>
>>could change the HTTPTransport to look nicer. But, we needed a fix
>>
>>
>quickly
>
>
>>so we didn't do this. Again we will raise a JIRA bug report to not lose
>>
>>
>it.
>
>
>>In General - I thought that there was discussion around removing the
>>HTTPTransport layer and replacing it with libwww? I think that this
>>
>>
>would
>
>
>>be a really good idea. We get so much for free with that library. It is
>>nice and modular and seems to not have had any new fixes for over two
>>
>>
>years
>
>
>>which (I think) shows how stable it must be.
>>
>>What does the dev community think to this?
>>
>>
>>
>>
>>John Hawkins,
>>
>>
>>
>>
>> "cheng liang"
>> <chengliang2004@h
>> otmail.com>
>>
>>
>To
>
>
>> axis-c-dev@ws.apache.org
>> 30/04/2004 04:28
>>
>>
>cc
>
>
>>
>>
>Subject
>
>
>> Please respond to Re: HTTP chunked problem
>> "Apache AXIS C
>> Developers List"
>>
>>
>>
>>
>>
>>
>>
>>
>>hi, Adrian Dick,
>>
>>Thanks.
>>
>>I used this code and it work fine on windows.
>>
>>But I want to point that in the following code in httptransport.cpp:
>>
>>if((pos = strLine.find("Content-Length:")) !=
>> std::string::npos)
>>{
>> m_intBodyLength = atoi(strLine.substr
>> (pos + strlen("Content-Length: ")).c_str());
>>}
>>
>>there is some exception.
>>
>>The message got from the server (apache+axis(java)+tomcat) does not
>>
>>
>contain
>
>
>>the
>>code "Content-Length:".
>>
>>The http header is as follows:
>>
>>-------------------------------------------------------------
>>HTTP/1.1 200 OK
>>Content-Type: text/xml;charset=utf-8
>>Transfer-Encoding: chunked
>>Date: Fri, 30 Apr 2004 03:06:52 GMT
>>Server: Apache-Coyote/1.1
>>-------------------------------------------------------------
>>
>>
>
>_________________________________________________________________
>享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
>
>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
RE: HTTP chunked problem
Posted by Susantha Kumara <su...@opensource.lk>.
According to the XML-Pull base architecture of Axis C++ its difficult to
support href. May need some architecture changes which will probably
affect performance.
What does WS-I say about supporting href, multiRef ?
---
Susantha.
-----Original Message-----
From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
Sent: Tuesday, May 04, 2004 2:09 PM
To: Apache AXIS C Developers List
Subject: Re: HTTP chunked problem
The code cannot deal with href's at the moment.
We would like href's soon and we are working on a way to find out how to
do
this.
John Hawkins,
"cheng liang"
<chengliang2004@h
otmail.com>
To
axis-c-dev@ws.apache.org
03/05/2004 00:51
cc
Subject
Please respond to Re: HTTP chunked problem
"Apache AXIS C
Developers List"
Hi, John,
I think you should put HTTPChunking resolution code in the channel
layer.
This will make the httptransport code seems more consistent since the
difference will be solved in the below layer.
As for libwww, I have not used it yet. If it is strong enough, it would
be
a good choice.
My major concern is the Class Object Deserialization problem. As I
mentioned,
the existing code could not deal with it correctly. The code could not
recognize
the "href" attribute, and treat it correctly.
The payload is as follows:
------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSc
hema-instance">
<soapenv:Body>
<ns1:getUserResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/en
coding/"
xmlns:ns1="http://10.7.0.237:8080/SysPlatform/services/UserClass">
<ns1:getUserReturn href="#id0"/>
</ns1:getUserResponse>
<multiRef id="id0" soapenc:root="0"
soapenv:encodingStyle="http://schemas.xmls
oap.org/soap/encoding/" xsi:type="ns2:UsersWS"
xmlns:soapenc="http://schemas.xml
soap.org/soap/encoding/" xmlns:ns2="urn:BeanService">
<address xsi:type="xsd:string"></address>
<birthday xsi:type="xsd:date">1986-01-01</birthday>
<certificateCategory
xsi:type="xsd:string">category</certificateCategory>
<certificateNumber xsi:type="xsd:string"></certificateNumber>
<collaboratorId xsi:type="xsd:int">0</collaboratorId>
<country xsi:type="xsd:string">cn</country>
<description xsi:type="xsd:string"></description>
<email xsi:type="xsd:string"></email>
<handset xsi:type="xsd:string"></handset>
<handsetBand xsi:type="xsd:string" xsi:nil="true"/>
<msn xsi:type="xsd:string"></msn>
<nickName xsi:type="xsd:string">test2</nickName>
<password xsi:type="xsd:string">111111</password>
<postalcode xsi:type="xsd:string"></postalcode>
<province xsi:type="xsd:string">31</province>
<qq xsi:type="xsd:string"></qq>
<question xsi:type="xsd:string">hello</question>
<realName xsi:type="xsd:string"></realName>
<registerIp xsi:type="xsd:string">10.7.0.10</registerIp>
<registerTime
xsi:type="xsd:dateTime">2004-04-27T19:57:17.000Z</registerTime>
<result xsi:type="xsd:string"></result>
<secondPassword xsi:type="xsd:string" xsi:nil="true"/>
<sex xsi:type="xsd:string">0</sex>
<telephone xsi:type="xsd:string"></telephone>
<userId xsi:type="xsd:long">23</userId>
<userName xsi:type="xsd:string">test2</userName>
<website xsi:type="xsd:string"></website>
</multiRef>
</soapenv:Body>
</soapenv:Envelope>
------------------------------------------------------------
I use the following code in client stub:
Ret = (UsersWS*)m_pCall->GetCmplxObject((void*)
Axis_DeSerialize_UsersWS,
(void*) Axis_Create_UsersWS,
(void*) Axis_Delete_UsersWS,
"return", 0);
I get that Ret equal NULL.
best,
Cheng Liang
>From: John Hawkins <HA...@uk.ibm.com>
>Reply-To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>CC: axis-c-dev@ws.apache.org
>Subject: Re: HTTP chunked problem
>Date: Fri, 30 Apr 2004 07:40:38 +0100
>
>
>
>
>
>Hi Cheng,
>
>fyi: Adrian, Fred Preston and I all work together so we answer
questions
on
>behalf of each other :-)
>
>Yes, I saw the HTTP Content length problem but it doesn't appear to be
used
>in the code for now so I left it. However, we'll raise it on JIRA so it
is
>not lost.
>
>The HTTP Transport in general has a few issues in its logic. The
underlying
>channel object isn't as good as it could be.. We had to put in some
hacky
>looking code for the HTTPChunking fix. I think that a better resolution
>would be to change the underlying channel object to work properly then
we
>could change the HTTPTransport to look nicer. But, we needed a fix
quickly
>so we didn't do this. Again we will raise a JIRA bug report to not lose
it.
>
>
>In General - I thought that there was discussion around removing the
>HTTPTransport layer and replacing it with libwww? I think that this
would
>be a really good idea. We get so much for free with that library. It is
>nice and modular and seems to not have had any new fixes for over two
years
>which (I think) shows how stable it must be.
>
>What does the dev community think to this?
>
>
>
>
>John Hawkins,
>
>
>
>
> "cheng liang"
> <chengliang2004@h
> otmail.com>
To
> axis-c-dev@ws.apache.org
> 30/04/2004 04:28
cc
>
>
Subject
> Please respond to Re: HTTP chunked problem
> "Apache AXIS C
> Developers List"
>
>
>
>
>
>
>
>
>hi, Adrian Dick,
>
>Thanks.
>
>I used this code and it work fine on windows.
>
>But I want to point that in the following code in httptransport.cpp:
>
>if((pos = strLine.find("Content-Length:")) !=
> std::string::npos)
>{
> m_intBodyLength = atoi(strLine.substr
> (pos + strlen("Content-Length: ")).c_str());
>}
>
>there is some exception.
>
>The message got from the server (apache+axis(java)+tomcat) does not
contain
>
>the
>code "Content-Length:".
>
>The http header is as follows:
>
>-------------------------------------------------------------
>HTTP/1.1 200 OK
>Content-Type: text/xml;charset=utf-8
>Transfer-Encoding: chunked
>Date: Fri, 30 Apr 2004 03:06:52 GMT
>Server: Apache-Coyote/1.1
>-------------------------------------------------------------
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
Re: HTTP chunked problem
Posted by John Hawkins <HA...@uk.ibm.com>.
The code cannot deal with href's at the moment.
We would like href's soon and we are working on a way to find out how to do
this.
John Hawkins,
"cheng liang"
<chengliang2004@h
otmail.com> To
axis-c-dev@ws.apache.org
03/05/2004 00:51 cc
Subject
Please respond to Re: HTTP chunked problem
"Apache AXIS C
Developers List"
Hi, John,
I think you should put HTTPChunking resolution code in the channel layer.
This will make the httptransport code seems more consistent since the
difference will be solved in the below layer.
As for libwww, I have not used it yet. If it is strong enough, it would be
a good choice.
My major concern is the Class Object Deserialization problem. As I
mentioned,
the existing code could not deal with it correctly. The code could not
recognize
the "href" attribute, and treat it correctly.
The payload is as follows:
------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSc
hema-instance">
<soapenv:Body>
<ns1:getUserResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/en
coding/" xmlns:ns1="http://10.7.0.237:8080/SysPlatform/services/UserClass">
<ns1:getUserReturn href="#id0"/>
</ns1:getUserResponse>
<multiRef id="id0" soapenc:root="0"
soapenv:encodingStyle="http://schemas.xmls
oap.org/soap/encoding/" xsi:type="ns2:UsersWS"
xmlns:soapenc="http://schemas.xml
soap.org/soap/encoding/" xmlns:ns2="urn:BeanService">
<address xsi:type="xsd:string"></address>
<birthday xsi:type="xsd:date">1986-01-01</birthday>
<certificateCategory
xsi:type="xsd:string">category</certificateCategory>
<certificateNumber xsi:type="xsd:string"></certificateNumber>
<collaboratorId xsi:type="xsd:int">0</collaboratorId>
<country xsi:type="xsd:string">cn</country>
<description xsi:type="xsd:string"></description>
<email xsi:type="xsd:string"></email>
<handset xsi:type="xsd:string"></handset>
<handsetBand xsi:type="xsd:string" xsi:nil="true"/>
<msn xsi:type="xsd:string"></msn>
<nickName xsi:type="xsd:string">test2</nickName>
<password xsi:type="xsd:string">111111</password>
<postalcode xsi:type="xsd:string"></postalcode>
<province xsi:type="xsd:string">31</province>
<qq xsi:type="xsd:string"></qq>
<question xsi:type="xsd:string">hello</question>
<realName xsi:type="xsd:string"></realName>
<registerIp xsi:type="xsd:string">10.7.0.10</registerIp>
<registerTime
xsi:type="xsd:dateTime">2004-04-27T19:57:17.000Z</registerTime>
<result xsi:type="xsd:string"></result>
<secondPassword xsi:type="xsd:string" xsi:nil="true"/>
<sex xsi:type="xsd:string">0</sex>
<telephone xsi:type="xsd:string"></telephone>
<userId xsi:type="xsd:long">23</userId>
<userName xsi:type="xsd:string">test2</userName>
<website xsi:type="xsd:string"></website>
</multiRef>
</soapenv:Body>
</soapenv:Envelope>
------------------------------------------------------------
I use the following code in client stub:
Ret = (UsersWS*)m_pCall->GetCmplxObject((void*) Axis_DeSerialize_UsersWS,
(void*) Axis_Create_UsersWS,
(void*) Axis_Delete_UsersWS,
"return", 0);
I get that Ret equal NULL.
best,
Cheng Liang
>From: John Hawkins <HA...@uk.ibm.com>
>Reply-To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>CC: axis-c-dev@ws.apache.org
>Subject: Re: HTTP chunked problem
>Date: Fri, 30 Apr 2004 07:40:38 +0100
>
>
>
>
>
>Hi Cheng,
>
>fyi: Adrian, Fred Preston and I all work together so we answer questions
on
>behalf of each other :-)
>
>Yes, I saw the HTTP Content length problem but it doesn't appear to be
used
>in the code for now so I left it. However, we'll raise it on JIRA so it is
>not lost.
>
>The HTTP Transport in general has a few issues in its logic. The
underlying
>channel object isn't as good as it could be.. We had to put in some hacky
>looking code for the HTTPChunking fix. I think that a better resolution
>would be to change the underlying channel object to work properly then we
>could change the HTTPTransport to look nicer. But, we needed a fix quickly
>so we didn't do this. Again we will raise a JIRA bug report to not lose
it.
>
>
>In General - I thought that there was discussion around removing the
>HTTPTransport layer and replacing it with libwww? I think that this would
>be a really good idea. We get so much for free with that library. It is
>nice and modular and seems to not have had any new fixes for over two
years
>which (I think) shows how stable it must be.
>
>What does the dev community think to this?
>
>
>
>
>John Hawkins,
>
>
>
>
> "cheng liang"
> <chengliang2004@h
> otmail.com>
To
> axis-c-dev@ws.apache.org
> 30/04/2004 04:28
cc
>
>
Subject
> Please respond to Re: HTTP chunked problem
> "Apache AXIS C
> Developers List"
>
>
>
>
>
>
>
>
>hi, Adrian Dick,
>
>Thanks.
>
>I used this code and it work fine on windows.
>
>But I want to point that in the following code in httptransport.cpp:
>
>if((pos = strLine.find("Content-Length:")) !=
> std::string::npos)
>{
> m_intBodyLength = atoi(strLine.substr
> (pos + strlen("Content-Length: ")).c_str());
>}
>
>there is some exception.
>
>The message got from the server (apache+axis(java)+tomcat) does not
contain
>
>the
>code "Content-Length:".
>
>The http header is as follows:
>
>-------------------------------------------------------------
>HTTP/1.1 200 OK
>Content-Type: text/xml;charset=utf-8
>Transfer-Encoding: chunked
>Date: Fri, 30 Apr 2004 03:06:52 GMT
>Server: Apache-Coyote/1.1
>-------------------------------------------------------------
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com