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.
