cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <>
Subject Re: Aegis Overview
Date Sat, 22 Sep 2007 20:21:23 GMT
Benson Margulies wrote:
> 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.  
Yeah, as I mentioned before: originally it was Java5->XML->Default. So 
maybe I screwed it up in the current code base. I will look into 1043 
and see what I can find out though.

Re: cooperation - IIRC, there were some cases it was hard to determine 
what was the right thing to do. It definitely wasn't designed the 
XML->Java5 delegation in mind though.
> 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.
I'm really not sure - theoretically it sounds feasible though. I do 
wonder if it'd be worth the extra time though.

Good summary of how things work though. Seems you're getting the hang of 
my crappy code. Apologies for its ugliness - its many years old and I've 
learned many lessons since then. I certainly wouldn't do it this way 
again :-)

- Dan

Dan Diephouse
MuleSource |

View raw message