cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Incoming change from me that might not be likable around part configuration in the RFSB
Date Sun, 23 Aug 2009 12:10:10 GMT
There's an ancient festering mess in Aegis related to the documented
capability to configure schema characteristics of method parameters.
It's the usual three stooges: minOccurs, maxOccurs, and nillable.

Aegis has a lot of confusion to go around here. In general, Aegis type
objects carry these attributes. This is probably deeply wrong, since
they are attributes of elements, not types, and things would work
better if the data model of Aegis in fact paralleled the data model of
XML Schema in this regard.

Fixing that would be a rather giant project.

For arrays, Aegis is constantly manufacturing new type objects, and so
this problem is not so bad. Each distinct Type for an array can have
the attributes from XML.

For basic types, on the other hand, Aegis has a split personality. The
ancient doc on the XML files claims that you can tweak any element.
The actual implementation sets the nillable property based on the type
creation options, and ignores the XML.

At the moment, I'm working on the 'parameter' case, though I suspect
that there are parallel things wrong with bean elements. Perhaps not,
since the BeanType has the ability to work around some of these

At the end of the day, parameters are parts, which tend to end up
wrapped up as wrapper parts.

I added code to AegisDatabinding so that non-default specifications of
minOccurs, maxOccurs, and nillable are always set onto the
MessagePartInfo as properties. Thus, even though the Aegis
'StringType' will always have nillable taken from the type creation
options, a particular String parameter with nillable='false' ends up
with a suitable property.

Just this much wasn't good enough. Why? Because RFSB didn't respect
these three properties. It called the service configuration object to
pull them from the MessagePartInfo, and AbstractServiceConfiguration
doesn't look at any properties. DefaultServiceConfiguration does, but
it didn't get called.

So I've ended up with more or less copies of the methods for this
purpose on the AbstractServiceConfiguration class.

As I write this, I find myself thinking that this is nuts, so I'm
going back to the debugger to try to explain howcome I'm not seeing
the DefaultServiceConfiguration in play in my test cases, and maybe
this email will prove self-cancelling.

View raw message