cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From relphie <>
Subject Re: Circular initialization muddle in Aegis
Date Mon, 16 Mar 2009 14:42:28 GMT

Haven't seen any other traffic on this, and with 2.2 looking at a release
soon, I was wondering if we could get your best-practice idea implemented -
create and add a new DefaultTypeMapping to the binding.  Is this basically
the way in which the default mappings for the various Java types are added?

bimargulies wrote:
> 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.

View this message in context:
Sent from the cxf-dev mailing list archive at

View raw message