What about this case then?
@GET @Path("/")
public String foo(@QueryParam("bar") @DefaultValue("baz") String bar) {
...
}
I'd be surprised and annoyed if this caused bar to contain "baz" when
calling it with "GET /?bar=". Don't send parameters if you don't intend to
give a value.
2011/4/4 kenglxn <ken_at_glxn.net>
>
> Daniel Larsson wrote:
> >
> > Hmm, I'm not sure I'd call this a bug. Default values are for parameters
> > that have no value passed in to them. A blank value is not the same as
> > absence of a value, so it seems a bit weird to apply a default value in
> > this
> > case.
> >
>
> I think if you use @DefaultValue, then absence of value and blank value
> should have the same behaviour.
>
> Given:
> @GET @Path("/")
> public String foo(@QueryParam("size") @DefaultValue(42) int size) {
> return ""+size;
> }
>
> Then:
> * "GET /" returns "42"
> * "GET /?size=0" returns "0"
> * "GET /?size=" returns HTTP 404
>
> In the last request we never even get to the resource due to a
> NumberFormatException in PrimitiveValueOfExtractor, and the end user is
> presented with a HTTP 404 which is misleading since the resource exists.
>
> My thought is that there should be a use case for supplying a blank
> parameter to something annotated with @DefaultValue for this to not be a
> bug.
> I could not think of such a use case.
> If you have @DefaultValue on the parameter, should this not behave the same
> for nonexistent and blank parameters?
>
>
>
> --
> View this message in context:
> http://jersey.576304.n2.nabble.com/DefaultValue-with-empty-string-tp5657597p6237748.html
> Sent from the Jersey mailing list archive at Nabble.com.
>