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.
Marek
>
> Cheers, Sergey
>
>>
>> On 9/9/2013 8:06 AM, Sergey Beryozkin wrote:
>>> Hi All,
>>>
>>> One thing which was agreed earlier was that ReaderInterceptor or
>>> WriterInterceptor are run only after a relevant MBR or MBW has been
>>> selected.
>>>
>>> Given this fact, can Reader or Writer interceptor effectively 'lose' the
>>> initial MBR or MBW they wrap by updating the class of the entity, etc ?
>>>
>>> For example, I'm seeing a number of early TCK tests where a provider say
>>> for List has been selected, the readers wrapping this List provider are
>>> invoked, the entity class is changed to LinkedList and thus the
>>> initially wrapped List MBR is expected to be ignored and a new
>>> LinkedList MBR invoked.
>>>
>>>
>>> Thanks, Sergey
>>
>