I'm trying to prepare to work on Aegis support for wsdl2java. I'd like to ask Dan, Dan, and anyone else with some understanding of the design theory of Aegis to comment on the following summary how Aegis is supposed to work.
Aegis starts work when presented with a class, property, method, or parameter. In the default configuration, (and the only supported one AFAIK), there are three layers of processing: XML, Java5, and Default. The XML type creator gets the first bash at the problem, and it defers to the Java5 type creator, and if all else fails, the process reverts to the default creator. It seems pretty clear that the XML type creator and the default type creator are cooperative: if an XML mapping annotation just supplies one fact about a property, the rest of the information from the default creator is used. In some cases, this is also true of Java5. In other cases, once the XML creator sees any XML for an item, the Java5 creator is boxed out of the process. See CXF-1043. I think that this is a bug, but I'm not clear on, architecturally, how it should be resolved. The XML type creator defers to the rest of the chain in different ways in different places. I'm led to wonder whether this would be simpler or more reliable with a different strategy of running the creators in the opposite order: first, fill in a TypeClassInfo at the 'bottom', and then modify it towards the top. This assumes that the procedure of taking the contents of a TypeClassInfo and using it to build the actual type model is, in fact, completely independent of the type creator. That's not how the code works currently if I'm reading it correctly, but I can't tell if the design theory was that it should work this way. Anyway, we need to a spec of how this is all supposed to play so that I can have decide what xml to spit out in a wsdl2java for Aegis.
