axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Burati <>
Subject RE: Any tips/tricks for ApacheSOAP users moving to AXIS?
Date Wed, 18 Dec 2002 16:40:59 GMT

Ignore my specific comment/question about a registered serializer breaking
default deserializers - looks like that particular one was likely a coding
error on my part.  Still wondering if it's possible to register a
default/fallback deserializer though  (eg, anything you get back that's in a
namespace/encoding NOT registered in the mapping, then pass it off to this
deserializer (via factory)...   I can likely rework the code that was
depending on that to figure out that it's an XML type and to register our
IXml deserializer by return parameter 'name' and expected schema type, but
was just wondering if there was a way to do what this code I inherited was
successfully doing with ApacheSOAP via such fallback
serialization/deserialization handlers...

>  -----Original Message-----
> From: 	Mike Burati  
> Sent:	Tuesday, December 17, 2002 5:57 PM
> To:	''
> Subject:	Any tips/tricks for ApacheSOAP users moving to AXIS?
> 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

View raw message