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<[email protected]> 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<[email protected]> > 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. >> >
