Ouch, sorry, the first paragraph got mangled somehow,
I meant that in the early TCK I saw the readers/writers affecting the
selection of MBR/MBW
Cheers, Sergey
On 09/10/13 12:25, Sergey Beryozkin wrote:
> 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
>>
>