Has anyone written up a migration guide for getting from ApacheSOAP
(2.2/2.3) to AXIS? - particularly use of custom serializers/deserializers
and mapping registries? The documentation for custom mappings looks a bit
unfinished :-) and I'm going through the source now to figure out what's
going on under the covers, but any writeups (or pointers to pertinent
messages in the archives) would be helpful.
In particular, I'm investigating switching over one particular use of
ApacheSOAP to AXIS where
(a) WSDL may be fetched in a running JVM, that WSDL may then be parsed and
used by our own stuff (eg, not WSDL2Java or similar command line usage) and
then a SOAP Call built based on the WSDL,
and where (b) some of the parameters passed in the SOAP call may be XML
based complex types, but where they do NOT come from unique Java classes
representing those classes, but rather from a proprietary XML based object
format (eg, many different XML complex types may be represented by the same
Java Class) (not JDOM or DOM - but will likely be doing that too in the near
future).
- In ApacheSOAP, along with the default simple type mappings, we register a
DEFAULT serializer and deserializer for ANY unknown types, to map to this
particular XML representation (obviously allowing other mappings to override
it). Those will only be picked up if there's not a mapping registry match
by QName and encoding type first.
- That default mapping doesn't seem to have the same support level in AXIS
since if you try to pass a null QName in to a register mapping call, you get
back a JAX-RPC exception complaining about that null QName
Example (ApacheSOAP 2.2 / 2.3):
SOAPMappingRegistry smr = new SOAPMappingRegistry(xsd2001);
...
// Map the IXml class with any name to a custom IXmlSerializer - we'll
take care of adding xsi:type info
IXmlSerializer ss = new IXmlSerializer();
smr.mapTypes( Constants.NS_URI_SOAP_ENC, null, IXml.class, ss, null);
...
// Default any unknown (eg, not XSD simple types or other previously
registered type mappings) to IXml
Deserializer ds = new IXmlDeserializer();
smr.mapTypes(Constants.NS_URI_SOAP_ENC, null, null, null, ds);
It's non-obvious how to do such default mappings (without breaking anything
else) in AXIS from just the published docs - I'm guessing it can be done
based on a quick skim of the AXIS type mapping registry code, but was
looking for any recommendations on the right way to do such a default
mapping (fallback, if NO other mapping found).
Also, to make sure this runtime usage of AXIS (eg, where we're registering
everything via API, NOT individual type mapping descriptors and restarts of
AXIS) works as well as ApacheSOAP for us , I tried out equivalent uses of
ApacheSOAP (with our default mapping setup) and AXIS, from a SOAP Interop
Round2a test, to see how far I get, before attempting a full migration to
AXIS.
- Pass pretty much all Round2 tests using ApacheSOAP 2.2 (with some fixes I
had previously pulled in from 2.3)
- Without messing with ANY mapping/return type info, I can get this setup
(using our same client code but on top of AXIS1.1beta) to pass all the
echoSimpleType Round2 interop tests (INCLUDING arrays of those types), plus
echoBase64, with minimal changes to our code to swap ApacheSOAP API calls to
AXIS, against all those SOAP InteropRound2 servers returning XSI type info
in the transport data.
- By adding a setReturnType call to specify what we expect back for each
interop test service/method, we can then pass the simple type round 2 tests
against the rest of the round2 interop servers that don't specify type info
in the response data.
- BUT, to specify a return type, you have to specify parameters types/names?
Why is one tied to the other? (anyway, that was trivial for me to do since
I had the data for the WSDL from each Interop server - and it worked after
specifying that).
Ok, now that I got that far I went and ported our IXml (our own XML Java
representation for efficiency/speed/leniency for simple uses of XML)
Serializer and Deserializer from ApacheSOAP to AXIS and created factories
for each.
- Specifying the IXmlSerializer/factory for use with IXml.class via
call.registerTypeMapping(IXml.class, qname,
new
IXmlAXISSerializerFactory(IXml.class, qn),
null);
allowed me to get one step further and then make outgoing requests that took
IXml parameters (SOAPStruct represented as XML - for echoStruct in the SOAP
Interop Round2 tests) (I didn't hook up the deserializer yet since I was
looking to do that with the above defaults saying anything coming back that
we don't recognize as an XSD simple type or custom mapped type, use
IXmlDeserializtion to represent it as XML)...
Anyway, after registering this additional type mapping, I'm finding that ALL
the other echoSimpleType (eg, echoString, echoInteger ...) Round2 tests are
now failing trying to deserialize the responses. So, by doing nothing more
than adding a serializer mapping, I appear to have toasted the default
deserialization mappings for the XSD simple types. It's still serializing
the outgoing XSD simple type parameters for these tests as far as I can
tell, but just can't deserialize the result parameters... That makes little
sense to me - if adding a serialization mapping was going to override all
default mappings, I would've expected it to break all default serialization
mappings for simple types too, not just deserialization of those types.
Anybody got an explanation for that?
Should I be able to call Call.registerTypeMapping(...) to register an
additional type mapping, WITHOUT losing the XSD Default type mappings that
AXIS provides if you don't otherwise mess with it? I was expecting it to
work that way... If not, what's the recommended way to add a TypeMapping
(programmatically, not just via descriptor) while still delagating back to
the Default Type Mapping if a custom mapping isn't found or doesn't
match...?
Thanks in advance, I'm sure (at least I hope :-) the answers will become
obvious once I've spent some more time down in the guts of AXIS
implementation of TypeMapping Registries and such - but was hoping to get a
primer somewhere or advice on best practices for messing with type mappings
programmatically, for custom mappings and custom default mappings.
..Mike
