|
One of the trickier parts of the older versions
of WSIF was that to provide custom serializers or deserializers or special
assocations between xml types and java classes, you had to do something
provider-specific. More recently, there seems to be (part of?) a mechanism
that abstracts much of this, so that only the implementation and types of the
serializer and deserializer objects need to be provider-specific.
However, I can't figure out how to use this mechanism (based on reading the
source code of the latest nightly build.)
There seems to be a WSIFDynamicTypeMap on each
WSIFService, which, at least for the Axis provider, is passed on to each
WSIFPort and WSIFOperation. It appears to hold associations between xml
types (by QName) and java classes. It does not appear to hold
information about how to turn a chunk of XML of the given xml type into and
instance of the associated class, or vice versa, but rather to hope that this
information can be looked up in a default set of
serializer/deserializers.
There is another object, TypeSerializerInfo,
which is supposed to supply that serializer/deserializer info. It holds
the type association plus the relevant serializer and/or deserializer, where
presumably these objects are typed appropriately for the provider (e.g.
SerializerFactory or DeserializerFactory in Axis). However, these objects, stored in a List as an extra part on
WSIFMessages, would seem only to be used for default type mappings, not any
custom (de)serializers the client may need. And the constructor of
this object is not called anywhere in the wsif source as far as I can
tell.
Or perhaps I'm missing something?
Jeff
|
