You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by "Eric M. Dashofy" <ed...@ics.uci.edu> on 2000/08/22 01:39:27 UTC

Distinction between TypeMapping[] in DeploymentDescriptor and SOAPMappingRegistry...

New topic:

If I'm deploying a new object, and I want to map types for that object (i.e.
I want to assign serializers and deserializers for the various types that
I'll encounter interacting with that object), I have to pass the
DeploymentDescriptor a TypeMapping[].  I am unable to pass it a
SOAPMappingRegistry (or other XmlJavaMappingRegisty) instead because of the
API.  As far as I can see, the only time these type mappings get used is
when they are converted to a SOAPMappingRegistry internally anyway.

Now, I have an AutoSOAPMappingRegistry that extends SOAPMappingRegistry and
can do type-mapping automatically--it doesn't need an explicit mapping for
each type.  However, I am unable to use this in a DeploymentDescriptor since
DeploymentDescriptor's code is locked into using the base
SOAPMappingRegistry + TypeMapping[].

I could override DeploymentDescriptor.buildSOAPMappingRegistry() so it
returns an AutoSOAPMappingRegistry--but wait! That's a static method,
meaning that I can't override it since none of the internal callers (in the
API) will call my version--they'll call the version in DeploymentDescriptor.

So, why the distinction?  Unfortunately, while a TypeMapping[] can be
converted into a SOAPMappingRegistry, the opposite isn't true.  I can't
convert my AutoSOAPMappingRegistry into a TypeMapping[] because I don't, a
priori, know which types I'm going to be mapping.

So, shouldn't I be able to pass a SOAPMappingRegistry or
XmlJavaMappingRegistry to DeploymentDescriptor to do my type mapping?  Was
this just an oversight or is the distinction deliberate (i.e. there is some
really good reason I'm missing that requires the use of a TypeMapping[])?

-----
  Eric M. Dashofy <ed...@ics.uci.edu>
  Graduate Student Researcher, Information & Computer Science
  University of California, Irvine
  http://www.ics.uci.edu/~edashofy