I am still having problems with bean serialization. The order of my getter
and setters
is:
- to
- timeout
- topic
As you notice in the message previously sent, the serialized order became:
- timeout
- to
- topic
At this time, with additional code changes, but no changes to that bean
class it is:
- topic
- timeout
- to
I do notice that the BeanSerializer attempts to use the method order
retrieved from
reflective lookup. I believe, however, that this is not guaranteed to be
the same as
the order the methods are placed in source code. I did look at the class
file, and the
order of the methods _is_ preserved there, indicating that either the jvm
load to the global
constants pool does not preserve order, or the reflective lookup mechanism
does not (perhaps
it uses Set.toArray when assembling the response to getMethods).
Is there (or is there planned) a simple mechanism to allow a bean to specify
its order,
such as providing a method like Stirng[] parameterOrder() in the bean, doing
a reflective
invocation of this (if it exists) in the serializer, and using that property
order?
For example:
122,133c122,137
< for (int i=0; i < methods.length; i++) {
< Method method = methods[i];
< if (method.getName().startsWith("set")) {
< boolean found = false;
< for (int j=0; j < myPd.length && !found; j++) {
< if (myPd[j].getWriteMethod() != null &&
< myPd[j].getWriteMethod().equals(method)) {
< found = true;
< newPd[index] = myPd[j];
< index++;
< }
< }
---
>
> // TNB Add lookup for xsd:sequence ordering
> Method sequenceMethod = null; //cls.getMethod("sequence", new
Class[0]);
> if (sequenceMethod != null &&
> sequenceMethod.getReturnType() == String[].class &&
> (sequenceMethod.getModifiers() &
java.lang.reflect.Modifier.STATIC) != 0) {
> String[] params = (String[])sequenceMethod.invoke(null, new
Object[0]);
> for (int i=0; i < params.length; i++) {
> boolean found = false;
> String param = params[i];
> for (int j=0; j < myPd.length && !found; j++) {
> if (param.equals(myPd[j].getName())) {
> found = true;
> newPd[index] = myPd[j];
> index++;
> }
134a139,154
> }
> } else {
> for (int i=0; i < methods.length; i++) {
> Method method = methods[i];
> if (method.getName().startsWith("set")) {
> boolean found = false;
> for (int j=0; j < myPd.length && !found; j++) {
> if (myPd[j].getWriteMethod() != null &&
> myPd[j].getWriteMethod().equals(method)) {
> found = true;
> newPd[index] = myPd[j];
> index++;
> }
> }
> }
> }
Then in WSDL2Java, the sequence method should be generated for xsd:sequence
types and
need not be for xsd:all types.
Tom Boulos
-----Original Message-----
From: Glen Daniels [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 11:11 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Help with soap header serialization
Heh, I was just typing up a response but you beat me to it.
It is intentional that EVERYTHING is sent as multiref, because we "stream"
our serialization. In other words, if we're serializing an Object which
MIGHT be referred to later in the graph of this message, we serialize an
HREF instead and then write out all the actual multiref serializations at
the end, because we don't have a way to do back-references or to rewrite XML
which we've already serialized.
I suppose we could put in some sort of "don't multiref headers" switch....
--G
> -----Original Message-----
> From: Tom Boulos [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 06, 2002 1:55 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Help with soap header serialization
>
>
> I just answered my own question to the first:
> by using call.setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS,
> Boolean.FALSE);
> So my questions changes: Is it intentional that the default
> behavior for
> headers
> is that they are sent as multiRef?
>
> -----Original Message-----
> From: Tom Boulos
> Sent: Wednesday, February 06, 2002 10:23 AM
> To: '[EMAIL PROTECTED]'
> Subject: Help with soap header serialization
>
>
> I am using the client.Call object to set headers. When I do
> this it is
> serialized with
> the contents in a multiRef element, and the header is
> refering to it. The
> element is only
> used by that single header, but I do not see how to avoid the multiref
> serialization.
>
> Also, I am using the BeanSerializer, but the elements are
> being serialized
> in the wrong
> order. Is there a simple way to indicate to the serializer
> which order the
> parameters
> are to appear? The getter and setter methods in the class
> file _are_ in the
> order that
> I want, and I notice the if I were to provide bean info, that
> the order will
> still be
> derived via relective lookup.
>
> Code:
> call.registerTypeMapping(phc, new QName(postNS, "post"),
> org.apache.axis.encoding.ser.BeanSerializerFactory.class,
>
> org.apache.axis.encoding.ser.BeanDeserializerFactory.class, true);
> SOAPHeader h = new SOAPHeader(postNS, "post", ph);
>
> call.addHeader(h);
>
> Result:
> <?xml version="1.0" encoding="UTF-8"?>
> <SOAP-ENV:Envelope
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> <SOAP-ENV:Header>
> <ns1:post href="#id0"
> xmlns:ns1="http://grandcentral.com/schemas/post/v1"/>
> </SOAP-ENV:Header>
> <SOAP-ENV:Body>
> <good xmlns="http://nowhere.org/what";>
> <arg0 xsi:type="xsd:string">one</arg0>
> <arg1 xsi:type="xsd:string">two</arg1>
> <arg2 xsi:type="xsd:string">three</arg2>
> </good>
> <multiRef id="id0" SOAP-ENC:root="0" xsi:type="ns2:post"
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:ns2="http://grandcentral.com/schemas/post/v1";>
> <timeout xsi:nil="true"/>
> <to xsi:type="xsd:string">tboulos.grandcentral.com/client</to>
> <topic xsi:nil="true"/>
> </multiRef>
> </SOAP-ENV:Body>
> </SOAP-ENV:Envelope>
>
> ---
>
> Tom Boulos <[EMAIL PROTECTED]>
> Grand Central Communications
> http://www.grandcentral.com
>
