On Tuesday 16 November 2010 11:21:27 am Aki Yoshida wrote: ..............snip.................... > Technically, this is simple to fix and I tested my fix locally. But I > would like to hear if this is the preferred solution. > > My solution was to introduce a boolean property "usingNoneAddress" to > the addressing configuration bean. If this property is set to false, > the above none constant is not serialized (i.e., the enclosing element > is omitted). > > Alternatively, we can always omit serializing the elements containing > the above "none" constant without using any configurable option. But I > was not sure if someone is expecting this invalid "none" constant in > their "non-conformal" implementation. In this case, simply omitting > the elements may break their running scenarios.
Hmm... That's a good question. If you omit it, do any of our tests break? Honestly, I'd actually prefer a spec-correctness-by-default setup where it would be omitted normally, but maybe a setting to turn it back on in the case where someone has a non-conformant implementation. I haven't looked at that code very well, is that something that seems easily doable? -- Daniel Kulp [email protected] http://dankulp.com/blog
