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: http://www.nabble.com/Circular-initialization-muddle-in-Aegis-tp22467650p22539713.html Sent from the cxf-dev mailing list archive at Nabble.com.
