Aegis Overview

[Benson Margulies <bi...@basistech.com>]

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.

RE: Aegis Overview

[Benson Margulies <bi...@basistech.com>]

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
> 

Re: Aegis Overview

[Dan Diephouse <da...@mulesource.com>]

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