dev@jsr311.java.net

Re: JSR311: _at_FormParam if path is not matched to it's end [was: JSR311: why Request.getFormParameters() in JAX-RS?]

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Thu, 24 Jul 2008 12:23:51 -0400

After discussing this with Paul we agree with your original suggestion
and propose to restrict @FormParam usage to resource method
parameters. @FormParam is different to the other @*Param in that it
requires the entity body to be consumed so really it should be a peer
of the entity parameter and not available elsewhere.

Marc.

On Jul 16, 2008, at 3:18 PM, Stephan Koops wrote:

> Hi Marc,
>
> Marc Hadley schrieb:
>> On Jul 16, 2008, at 6:53 AM, Stephan Koops wrote:
>>> the read of an entity is only allowed for (sub) resource methods,
>>> because the entity should only be processed there. I think it is
>>> useful to think about to do the same with @FormParam, so that you
>>> can not inject it into resource class fields and bean setters, if
>>> the path is not fully parsed.
>>> Perhaps there are good arguments against this. What do you think?
>> A slightly different suggestion: if an @FormParam is encountered
>> before the resource method is called then any entity parameter MUST
>> be of type MultivaluedMap<String, String>.
>>
>> That way an implementation can consume the request entity as soon
>> as the first @FormParam is encountered and we don't restrict the
>> use of @FormParam.
> Also a solution. IMO not the best for design reasons, but the
> technical problems are resolved. And it's easy to use.
>
> Best regards
> Stephan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.