On Apr 27, 2012, at 3:52 PM, Bill Burke wrote:
>>
>
> Resteasy does not have a PreProcessor interceptor that reads the entity. You guys have a valid strong use case that does. It is a valid issue that we should talk about and work through to see what constraints we should add to the API or to see if we can get an improved API.
>
> I freaked out because I thought you were really serious about removing interceptors. Maybe start over and discuss again?
>
> I think:
>
> a) Removing generics might be a good idea. I've never used them. Have you guys? Then again, what if it could be used as a deployment check? If an typed interceptor is assigned to a resource method with non-matching types, it could be flagged at deployment time
The type parameter on all interceptor-related classes has already been removed (a few days back). There was a JIRA for that, and it is closed. There was no real use for it and created confusion.
> b) We should investigate the behavior of calling write/readEntity within a filter.
>
> c) Maybe writeEntity within PreProcessing should create its own interceptor chain based on the type and annotation[] array passed into it?
>
> d) Maybe readEntity() should automatically buffer the request?
>
> e) Maybe methods on ContainerRequestContext should be added like wasBuffered(), wasRead() etc., then other interceptors will know that a read/write/buffering happened?
I like interceptors in general, but I'm still worried about the complex interactions between them and the filters. The questions above touch in all the thorny points. If we can't explain the interaction between filters and interceptors in a few sentences, and with the help multiple new methods, then there's a problem IMO.
-- Santiago
PS: EDR3 is delayed, again, as its main purpose was to include the latest filter proposal.