cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: Incoming change from me that might not be likable around part configuration in the RFSB
Date Sun, 23 Aug 2009 12:22:21 GMT
I now see the root of this insanity. DefaultServiceConfiguration
refuses to take a minOccurs spec for a primitive type. I guess I'll be
removing that clause and seeing what happens to me.

On Sun, Aug 23, 2009 at 8:10 AM, Benson Margulies<> wrote:
> 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
> problems.
> 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