cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: Circular initialization muddle in Aegis
Date Mon, 16 Mar 2009 15:04:12 GMT
This is resolved for 2.2, and a test case derived from your code is
now one of the Aegis unit tests.

On Mon, Mar 16, 2009 at 10:42 AM, relphie <> wrote:
> 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