Dan, A couple of things:
1) I've packaged the whole ball of wax in 1054. 2) I think that my next activity will be to write a 1/2-ton of prose on the Wiki about how it currently works. With a little help from you in refining my understanding of the intent, that will (a) help users figure out what and how to subclass, and (b) clarify a way forward. I am sorely tempted to propose the following refactoring process: 0) Post a poll to the users list asking about how/why people are using Aegis. There are certainly some enthusiasts (including myself for some pieces). It might be easier to decide where to concentrate effort with some feedback. 1) Split type creation into XML, pseudo-JAXB, and everything else. Since CXF doesn't support 1.4, there's perhaps no need to distinguish 'Java5' from non-Java5. However, the support for some of the snails seems like a distinctive activity. In fact, I wonder if there's a way to define Aegis as parasitic on JAXB instead of competitive, as it were? That is, make the bottom type creator (at least optionally) be JAXB, and then XML can fill in or override its opinions? 2) By reducing the number of type creators in the stack, that's an opportunity to make the whole thing smaller and more readable. All this having been typed, I appreciate that there is a real question of the relative priority of Lipsticking the Aegis Pig versus other features that are the subject of clamor. When you ask, 'is it worth it,' the question you are posing is whether to do any more than the minimal patching of the code we've got to make the transitioning XFire users happy. As a matter of personal style, once I get entangled with something, my tendency is to just keep digging. That's doesn't necessarily lead to an optimal use of time -- and I won't always be able to commit the amount of time I've had available in the last few weeks. So if the community would rather see effort focused on the Javascript project, or any other thing from the global to-do list, I will take that direction. --benson > -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 22, 2007 4:21 PM > To: [email protected] > Subject: Re: Aegis Overview > > 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 > http://mulesource.com | http://netzooid.com/blog >
