hi tom, thanks you your reply. if you have already working with axis 1.x could you please help on answering these questions?
On Jan 3, 2008 4:06 AM, Tom Jordahl <[EMAIL PROTECTED]> wrote: > +1 on Glen's -1 of using a whole new set of types to support SOAP > encoding. A String must map to a soapenc:string and a Array[] must map > to a SOAP encoded array. In axis 1.x is it use in code first or contract first (i.e. wsdl2java) approach? Here what I am trying to do is to use it with the wsdl2java tool. i.e with the contract first approach. So the main question is what is the generated method signature for <s:element name="TestSoapElement2"> > <s:complexType> > <s:sequence> > <s:element name="param1" type="s:string"/> > <s:element name="param2" type="soapenc:Array"/> > </s:sequence> > </s:complexType> > </s:element> this type of element. what is the type of param2 in Axis 1.x? Here in code generation time I do not know the type of the array. That is why I set it as a new type letting users to define it. > > I would also argue for "full" multiref support, as servers will be > sending this back to Axis2 clients, right? I agree. I'll add this feature as I have describe earlier. > > > Amila, please feel free to use the Axis 1.x code base as a reference for > how to do any of this. Please also feel free to NOT to duplicate the > Array serialization/deserialization bugs. :-) For the moment in Axis 2 ADB is also in a very stable state. so using already existing ADB logic won't give any serializing de serializing issues. Thanks, Amila. > > > -- > Tom Jordahl > Axis 1.x guy > > > -----Original Message----- > From: Glen Daniels [mailto:[EMAIL PROTECTED] > Sent: Friday, December 28, 2007 1:49 AM > To: axis-dev@ws.apache.org > Subject: Re: [Axis2] Soap Encoding support with ADB > > Hey Amila: > > > won't need them. But for SOAP 1.1, the situation is different. > The > > encoding spec says you MUST encode all complex object types as > top-level > > members of the serialization. Therefore ALL conforming SOAP 1.1 > > encoding implementations will be putting out stuff that looks like > this: > > > > <soap:body> > > <operation> > > <arg1 href="#obj1"/> > > </operation> > > <multiref id="obj1"> > > <name>the real argument</name> > > <color>blue</color> > > </multiref> > > </soap:body> > > > > is this means it is allowed to have more than one xml element in the > > soap:body ? > > Yes. But - I was incorrect about the MUST above! My hands were typing > a little ahead of my brain there. :) Multirefs are not in fact > *required* by SOAP 1.1 section 5, but some implementations (Axis 1.X > included) will by default serialize all complex objects as multirefs > since it speeds writing (if you don't do it that way you have to walk > the entire data graph to see what objects are referred to multiple times > > before serializing). > > > I have to think about bit. We can resolve the problem with parsing as > I > > have mentioned earlier but can not think about a way to serialize with > > > multirefs. > > Again, my bad - we're not forced to do so, so it's ok for us not to, as > long as we accept that we're not going to be able to do real graphs. If > > no one wants this particular functionality, I'm fine with punting on it. > > Your idea about parsing the XML to remove the hrefs and generate a > larger "virtual" expanded document on the reading side should work fine, > > although it will potentially cause repeated data if a multiref is used > many times. Probably not a big deal. I'll respond to the rest of your > other note in another message. > > Thanks, > --Glen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Amila Suriarachchi, WSO2 Inc.
