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 13:36:49 GMT
Well, something of a faux alarm. It turns out that my code works fine
with no service config mods, though I'm going to go ahead and commit
some neatening of DefaultServiceConfiguration. I had messed up the
assert in the test case, convinced myself that the service config
wasn't cooperating, and then cured the test case.

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