cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies" <>
Subject Aegis Overview
Date Thu, 20 Sep 2007 12:58:02 GMT
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


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


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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message