Thanks Sergey. Just to confirm... the fix is available in Jettison 1.3.2 right? That is still an option?
The part about extending the JSONProvider (workaround) is not an option. Correct? I think we can wait. Although I will consider the Jackson approach as well. If this issue is resolved in Jettison 1.3.2, can you tell me when that Jettison release will be available and is it compatible with CXF 2.6.1? Thanks, Steve On Thu, Jul 12, 2012 at 8:26 AM, Sergey Beryozkin <[email protected]>wrote: > On 12/07/12 15:22, Sergey Beryozkin wrote: > >> Hi >> On 11/07/12 06:48, S K wrote: >> >>> Hello, >>> I have a REST service which supports JSON requests. When an element of >>> the >>> JSON object contains more than one of the same elements (e.g. "a") and >>> the >>> element is not defined as a collection, the last element found in the >>> request is set to the instance of the annotated bean for that element and >>> the first one is ignored/overwritten. The schema validation does not >>> catch >>> this is it would for an equivalent XML request. For example, below "a" is >>> an element which is defined once in the annotated class but when it >>> appears >>> more than once in the request, "a" will be set to 2. Is there a way I can >>> have my service recognize this JSON request contains more than one "a" >>> element, which is not allowed before allowing the request to continue? >>> The >>> requests are being validated by an XSD. I'm using CXF 2.6.1. >>> >>> { >>> "SomeRequest": { >>> "a":1, >>> "a":2, >>> "b":2 >>> }} >>> >>> >>> this is how the field is defined in the request class SomeRequest >>> @XmlElement(name = "a" , required=true) >>> private Long a; >>> >>> >>> >>> Schema element defined as: >>> <xs:element name="a" type="xs:long"/> >>> >> >> The problem was in Jettison which I've just fixed. Jettison can not >> stream at the moment so the values having identical keys were simply >> overwritten. So the good news is that Jettison 1.3.2 will have this >> issue fixed. >> >> The possible workaround is to extend JSONProvider and wrap the reader it >> creates with the custom reader which will do its own enforcement, >> example, it will block the payloads which will have more than one 'a' >> element... >> >> Sorry, this is not an option given that Jettison has already lost the > first 'a' by the time readers are asked for the data. > I'm afraid the only option then is to attempt to control the way the > client produces the payloads. Or do some kind of input stream filtering > which is messy... > Consider trying Jackson - that may help, though I'm not sure if the schema > validation can be plugged in there > > Cheers, Sergey > > thanks, Sergey >> >> >>> Thanks! >>> Steve >>> >>> >> > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ > > Blog: http://sberyozkin.blogspot.com >
