cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Circular initialization muddle in Aegis
Date Thu, 12 Mar 2009 00:38:35 GMT
Brian Relphie has run into a design problem in Aegis. I'm, at best,
too tired to sort it out tonight, but I can write it up.

Data bindings are called by service factories to initialize, and are
passed a Service object.

In the normal run of things, when Aegis gets this call, it sets up the
type mapping environment. Critically, it sets the 'mapping namespace
URI' to be the service's tns.

All automatically created mappings turn into XML Schema types in that namespace.

Brian tried to follow the sketchy instructions to add a custom
mapping. So, he created an AegisDatabinding and asked it for the
AegisContext, and asked THAT for the type map. And then he added his
types there.

The effect of this was to force the code to initialize the type
mapping system in a state of ignorance: with no knowledge of the
service TNS. As soon as the service goes to automatically create a new
type mapping (e.g. for a parameterized collection type) it goes into
the wrong namespace. As it happens, it goes into the XML schema
namespace, as there is a convention, carried over from XFire, of using
the XML Schema namespace as the official mapping URI when none better
is available.

The problem is circular: the custom mappings need to be registered
before the service initialization, but the service initialization is
needed to get the URI.

There is a workaround: create your own AegisContext and set the
mapping URI to something harmless, and the collection types will go
there. It's lame.

I think the right answer is might be  that someone like Brian should
be able to create their own DefaultTypeMapping for their custom types,
and pass that into the data binding  so that it will sit around until
service-driven initialization, and then just be placed at the head of
the chain of type mappings. As things are, calling getAegisContext is
a recipe for chaos due to this entirely unexpected side-effect of an
unwanted initialization of the type mapping.

Another line of attack is to allow the URI to change after creation of
the mapping. Given that this URI is used both as the home of
dynamically created types and also to select from multiple mappings in
.aegis.xml files, this could lead to surprises, but perhaps those
count as smaller surprises.

Yet another is this: if someone asks for the type mapping before full
initialization, create one with relatively harmless URI, and then
stack it up ahead of the service's mapping.

Mime
View raw message