If you have an MessageBodyReaderInterceptor that also implements AcceptedByMethod interface the accept() method is not called for any Resteasy services that have any of the resteasy method parameter annotations. For eg.

• @FormParam
• @QueryParam

Unless one of the arguments in the method does not have any annotation (in which case Resteasy assumes that it is the string body and associates the org.jboss.resteasy.core.MessageBodyParameterInjector instance with that parameter. Which internally calls the accept() method for the MessageBodyReaderInterceptor.

This may have been done with the assumption that if an interceptor exists which may potentailly change the input stream of the incoming request then @FormParam etc. are no longer supported.

This to me seems like a severe deficiency of the intereceptor framework.

Resteasy Interceptors should be able to provide :

• Repeatable Inputstreams for incoming requests so that multiple interceptors can read and change it if desired
• Resteasy services should be able to use @FormParam , @QueryParam annotations. (i.e Paramater marshalling should work fine) while at the same time be bound to MessageBodyReaderInterceptors.

I realize that there are some limitations that servlet containers such as Tomcat impose for eg. on Tomcat if you've read the input stream using getInputStream() on a request object then the getParameters*() methods no longer return anything and vice versa. However, I would think that since Resteasy already provides an abstraction layer over the HttpServletRequest it should be able to take care of that issue by always parsing the input stream and then retrieving the parameters from that stream.

I have filed this as a bug but I realize that depending on the intent of the developer owning the feature this may actually be an enhancement request.

Also note that the DKIMSignature verification interceptors don't work for any Resteasy services which have such method parameters for the same reason.

Coupled with issue https://issues.jboss.org/browse/RESTEASY-567 it becomes really difficult to use Interceptors for things like digital signature verification (our own custom ones, not DKIM) of the message content if reading the content implies we can't use the @FormParam etc. annotations on methods.