Johan,
Out of curiosity, is there any reason why you cannot solve your problem without using the Servlet API? E.g. using @FormParam?
-- Santiago
On Feb 5, 2014, at 6:13 AM, johan_at_lodgon.com wrote:
> I ran in an issue where CDI and JAX-RS 2 are not working together. In
> case a Resource class is also using CDI, parameters used in resource
> methods won't work (they might be empty).
>
> Checking the problem (with Jersey and Weld) showed this:
> A CDI implementation needs to provide a CDI Conversation Filter. In the
> Weld case, this filter calls ServletRequest.getParameter(). The servlet
> javadoc mentions
> "If the parameter data was sent in the request body, such as occurs
> with an HTTP POST request, then reading the body directly via
> getInputStream() or getReader() can interfere with the execution of
> this method."
>
> As a consequence, a single Filter implementation calling
> ServletRequest.getParameter() may consume the request body, which
> causes subsequent consumption of this request body to fail. Hence,
> using a MessageBodyReader (prepackaged or custom) will fail.
>
> Unless I am missing something, I don't think this is a flaw in CDI,
> Servlet spec, or JAX-RS, but the combination is not working. The whole
> JAX-RS spec implicitly assumes the method request body is available,
> but the combination of the Servlet spec and the CDI spec makes this
> impossible (there can only be 1 consumer of the method request body,
> either CDI or Jersey).
>
> More info on the issues:
>
> https://java.net/jira/browse/JERSEY-2356
> https://java.net/jira/browse/JERSEY-2340
> https://java.net/jira/browse/GLASSFISH-20957
> https://issues.jboss.org/browse/CDI-411
> https://issues.jboss.org/browse/WELD-1549
>
>
> - Johan