That gives the same result.
Jersey gives a nice warning about this:
"A servlet request to the URI
http://localhost:8080/1/content contains form
parameters in the request body but the request body has been consumed by
the servlet or a servlet filter accessing the request parameters. Only
resource methods using @FormParam will work as expected. Resource methods
consuming the request body by other means will not work as expected."
Jersey is able to "save" the @FormParams as it queries the
HttpServletContext and stores the FormParams internally (in a Form), but
that is a very implementation-specific (in
org.glassfish.jersey.servlet.WebComponent). The stored form parameters are
only accessed via the FormParamValueFactoryProvider, where using a
MultiValuedMap will leverage the MultivaluedParameterExtractor and passing
a Form will use the EntityParamValueFactory. In theory, Jersey could be
patched and make Form and MultivaluedMap return the passed values as well,
but that would be implementation-specific, as the spec states that the
InputStream containing the entity might be unusable.
- Johan
2014-02-05 Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>:
>
> On Feb 5, 2014, at 7:59 AM, Johan Vos <johan_at_lodgon.com> wrote:
>
> Good question. In my specific case, I don't know the names of the
> parameters (they can change at runtime), hence I use a
> MultivaluedMap<String, String>.
>
>
> What about the Form class?
>
> https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/Form.html
>
> -- Santiago
>
>
> 2014-02-05 Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
> :
>
>> 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
>>
>>
>
>