cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies" <bim2...@basistech.com>
Subject RE: Aegis Overview
Date Sun, 23 Sep 2007 14:35:03 GMT
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:dan.diephouse@mulesource.com]
> Sent: Saturday, September 22, 2007 4:21 PM
> To: cxf-dev@incubator.apache.org
> 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
> 


Mime
View raw message