On Apr 11, 2012, at 7:31 PM, Bill Burke wrote:
>
>
> On 4/11/12 8:04 AM, Marek Potociar wrote:
>>
>> So even though there would be a FilterableClientResponse, the client request filter would not be able to produce one?
>>
>>> Or maybe I'm just not understanding your concern? I don't care that much, just trying to see if things can be cleaned up more.
>>
>> Firstly, we should design filters to either work with contexts or messages. So if we are to make the changes on the response side, we should also make the same changes on the request side (ContainerRequest extends Request).
>>
>> And then, the conceptual difference between working with a context as opposed to working with a message in a filter is that you may only update the context, but you may completely replace the message. So message-based filter interfaces would need to look like:
>>
>> public Message filter(Message); // allows complete replacement or wrapping of the message
>>
>
> Too much like Servlet filters which are really hard to work with. This either requires a builder API, which is awkward to use, or for you to wrap a message (like servlet filters) which is a huge pain to do simple things (like override the input/output stream).
>
>
>> as opposed to context based:
>>
>> public void filter(Context); // context cannot be replaced or wrapped
>>
>> In such case we would also need to agree on what gets injected into the resource as a Request instance - I'd say it would have to be the last instance returned by the request filter chain.
>>
>
> Or a third approach, where you have completely mutable request and response interfaces. Which is something I advocated months ago.
Maybe we don't understand each other. In the above I was still assuming mutable message instances. All I am saying is that a "message filter" should be able to wrap a response and return the wrapped response, whereas "context filter" should only be able to update the context, but not wrap it.
>
>
>> Note that I am not strictly against the above. The one disadvantage I can see as an API designer is that once we take this approach we will not be able to update the involved message interfaces anymore.
>>
>
> You're saying if we do the Message filter(Message) approach, we may be screwed in the future if we need to add something that is non-message based?
Yes.
> I see your point. Ok, i'm fine ditching this idea.
Ok :)
Marek
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com