On 5/10/12 3:42 PM, Marek Potociar wrote:
> All,
> thanks for the useful discussion so far. Let me summarize what I see as
> something we can (hopefully) agree upon:
>
> 1. ContainerRequestFilterContext
> * remove writeEntity()
> * keep readEntity()
> o invokes interceptors
> o does not buffer automatically
> * keep bufferEntity()
> o buffers un-intercepted entity stream
> * keep get/setInputStream()
> o these methods by-pass interceptors
> o invoking setInputStream resets the "buffered flag"
> * additional isRead/Buffered etc. methods might be proved as
> useful, but might be an overkill for now
> o we can add those later if we find out they are really needed
I agree with #1
> 2. Interceptors
> * reader interceptors are invoked on inbound data, writer on
> outbound data only
If writeEntity() is removed, then this point is moot no?
Then again, is buffered data considered "inbound"?
> 3. Other business
> * adding support for a Feature on the server side would be nice
> o needs to distinguish the side either via separate interface
> or annotation
> * @Provider is significant only for the purpose of scanning,
> otherwise it should not be required.
>
>
> Let me know if there are any objections to the above.
>
> Now a few open points:
>
> 1. interceptors are global only (? not sure if we can all agree on that)
Absolutely not. Annotations triggering interception is really useful
(just see CDI). Resteasy has a number of filters/interceptors triggered
by annotations applied to resource methods.
> 2. in pre-matching filters the readEntity() creates and invokes
> interceptor chain based on (any?) annotations passed to the method
+1.
> * still not sure here what is the proposed mechanism / API to
> allow the interceptor chain assembly
Not sure what you mean.
>
> Let's now try to focus on resolving the open points as well as any
> objections to the closed points.
>
> As for the open points, I am 50-50 here:
> If we agree on #1 we don't need to solve issues around #2 but we may
> miss some use cases (which I'm still not fully convinced about).
> OTOH, if we choose #2, we would not miss any potential use cases but we
> would most likely make the readEntity() unusable in pre-matching
> filters. Also I don't like the idea forcing people to instantiate
> annotations with #2 - there is no standard way how to do it which
> potentially breaks the portability of the code.
While there are ways to instantiate annotations, a name-bound
interceptor could have access to the resource-method's annotation[] array.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com