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