axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: HTTP chunked problem
Date Fri, 07 May 2004 04:12:09 GMT
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 <HAWKINSJ@uk.ibm.com>
>>>Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
>>>To: "Apache AXIS C Developers List" <axis-c-dev@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


Mime
View raw message