On 3/5/12 3:17 PM, Santiago Pericas-Geertsen wrote:
>
> On Mar 5, 2012, at 11:17 AM, Bill Burke wrote:
>
>> Give me a usecase where a filter implementation (other than logging) *WOULD* be shared between client and server. In my experience, it will usually be the case that you *cannot* share filters between client and server. For example, an authentication filter is server-only. A browser-like cache is client-only. In both of these examples, you would actually make the client or server unusable at runtime if they were shared by accident (like say via scanning).
>>
>> All this is because the semantics of a RequestFilter are totally different from client and server. A RequestFilter on the server is reading and processing incoming requests. On the client, a RequestFilter is writing and sending outgoing requests. Sharing will occur mostly within Reader/Writer interceptors because the semantics of incoming/outgoing are encapsulated within these interfaces already.
>
> I understand your proposal now. At first glance, I thought you were proposing to split everything, including interceptors. I tend to agree with your observation about filters.
>
> I'm still not sure I prefer an API with more types to discern these cases in favor of a more general one with some illegal state exceptions. Need to think this through more. There's value in keeping the number of interfaces down.
>
> As for the scanning problem, I agree it's an issue that needs to be resolved one way or the other.
The thing is, with specific types, you're less likely to make a mistake
like forget a scoping annotation. Or, if somebody creates a client
library you want to include in your server app, what if they just
ignored the scoping annotations?
Plus, if you look at the proposal, it cleans up a few other
inconsistencies that I've whined about.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com