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<bimargul...@gmail.com> 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. >
