Amila,
SOAP encoding is much more likely to be used in a code-first scenario,
but you must make sure that it also works in a WSDL-first scenario.
Regarding one of your questions, you would never see an element
defined as follows:
<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>
First off, you would define a named complexType rather than an
element. And second, you never define an element simply as
soapenc:Array. The ComplexType would look something like this:
<s:complexType name="TestSoapType2">
<s:sequence>
<s:element name="param1" type="soapenc:string"/>
<s:element name="param2" type="tns:ArrayofString"/>
</s:sequence>
</s:complexType>
<complexType name="ArrayOfString">
<complexContent>
<restriction base="soapenc:Array">
<attribute ref="soapenc:arrayType"
wsdl:arrayType="string[]"/>
</restriction>
</complexContent>
</complexType>
Or even more likely, you wouldn't define the "TestSoapType2" type --
you would simply reference the child types in the WSDL message
description:
<w:message name="TestInput">
<w:part name="param1" type="soapenc:string"/>
<w:part name="param2" type="tns:ArrayofString"/>
</w:message>
You might find this article helpful:
http://www.developer.com/services/article.php/10928_1602051_3
You also might spend a little time playing with Axis generating some
RPC/encoded services to get a better sense of how the environment
works.
Anne
On Jan 3, 2008 1:51 AM, Amila Suriarachchi <[EMAIL PROTECTED]> wrote:
> hi tom,
>
> I went through the Axis user guide[1] and as I understood Axis 1.x has used
> soap encoding in the
> code first approach to support Arrays. I think this is where both you and
> glen has misunderstood.
>
> in that case if I have a class like this
>
> public class Test {
> private int[] testArray;
> public void setTestArray(int[] param){
> testArray = param;
> }
>
> public int[] getTestArray(){
> return testArray;
> }
>
> }
>
> in this case as Axis 1.x has done users must be given the chance to deal
> with the standard types and it is
> almost useless to ask to deal with a new type. Further as I guess it uses
> org.apache.axis.providers.java.RPCProvider as in Axis2 RPCMessageReceiver.
> BTW one question. Why Axis 1.x use soap encoding for this? why it simply
> generate something
> like this
> <element name="testArray" minOccurs="0" maxOccurs="unbounded"/>
> it is always better to use POX rather than encoding types isn't it?
>
> So we won't be able to use the Axis 1.x code for this.
>
> But In the contract first approach people always have to deal with the
> generated classes. So I believe in this
> case I don't think it is a problem. Here the main idea is to access a
> service already deployed with soap:encoding.
>
> So it would only be used at client side.
>
> [1]
> http://ws.apache.org/axis/java/user-guide.html#ConsumingWebServicesWithAxis
>
> thanks,
> Amila.
>
>
>
> On Jan 3, 2008 10:53 AM, Amila Suriarachchi <[EMAIL PROTECTED]>
> wrote:
> > 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.
>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
