All,
Yet more fun doc/lit questions! This is all on the server-side now, I was able to
successfully hack the WSDL generated for wrapped style services with arrays to ditch
the soap encoding that axis currently dumps and was able to get a .net service to at
least generated stubs. Unfortunately, now I'm seeing issues when serializing back to
the client.
I have a custom serializer for my doc/lit service where I'm issuing statements like
the following:
--------------------------------------
public void serialize(QName qName, Attributes attributes, Object o,
SerializationContext context) throws IOException {
HotelAvailabilityListResult result = (HotelAvailabilityListResult) o;
context.startElement(qName, attributes);
context.serialize(new QName("", "moreResultsAvailable"), null,
new Boolean(result.isMoreResultsAvailable()));
context.serialize(new QName("", "propertyList"), null,
result.getPropertyList());
context.serialize(new QName("", "cacheKey"), null, result.getHotelCacheKey());
context.endElement();
}
--------------------------------------
The problem here is that everything seems to be panning out BUT, I'm getting
soap-encoded array types in the response stream (watching via SOAP Monitor) and .NET
isn't able to digest -- it's operating under the assumption that it's (.NET) dealing
with a doc/lit service and Axis is spitting back soap-encoding. Perhaps I'm missing
something in the details here, but I'm not sure how to prevent Axis from attempting to
encode array types in a custom serializer.
<propertyList soapenc:arrayType=":HotelAvailability[20]"
xmlns:soapenc="http://schemas...."/>
Axis and doc/lit don't seem to be playing well together on several fronts?
Cory
