Hi Bill,
I've got a different behavior from the early TCK, as soon as I relaxed
CXF code and allowed the MBR/MBW selection be done after the ; I don't
really care now to be honest about the order, I can reader/writers are
run, many failing tests started passing.
May be it is all different now in the latest TCK, no idea :-)
Marek, FYI, you confirmed the other day that reader/writers are run only
if MBW/MBR have already been selected, but only on this list, I agree
the spec says nothing.
I don't really mind which way it is done now, I guess given the
writer/reader API capabilities it can only be one way, reader/writers
first, MBR/MBW next
Sergey
On 08/10/13 13:25, Bill Burke wrote:
>
>
> On 10/7/2013 4:13 AM, Marek Potociar wrote:
>>
>> On Sep 9, 2013, at 2:41 PM, Sergey Beryozkin <sberyozkin_at_talend.com>
>> wrote:
>>
>>> On 09/09/13 13:27, Bill Burke wrote:
>>>> I ran into the same problem. I didn't think we agreed on that, but
>>>> when
>>>> you think about it, the interceptor can change the content-type so it
>>>> makes sense the writer/reader would change underneath.
>>>
>>> Yes, I agree, I guess Writer or Reader context implementations should
>>> be prepared to deal with the change of the properties which were used
>>> to select the currently wrapped provider, though I'd say the if the
>>> current MBR or MBW is still capable (isReadable or isWriteable still
>>> returns true) then it should be used
>>
>> Spec does not define anything like "current" reader/writer. IOW, the
>> spec does not mandate entity provider to be selected prior entity
>> interceptors are invoked.
>>
>
> And yet the TCK tests this very thing...
>
> Bill
>