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 Susantha Kumara <su...@opensource.lk> on 2004/05/10 07:07:44 UTC
href - multiRef support - [WAS]RE: HTTP chunked problem
> -----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