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: [email protected]
> > 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.
