@DefaultValue with empty string

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

@DefaultValue with empty string

Michael Mogley
It seems that a parameter passed in with an empty string will not trigger substitution of the default value.  Is it possible to somehow configure Jersey to switch this behavior to perform substitution of the default in such cases?

Michael
Reply | Threaded
Open this post in threaded view
|

Re: @DefaultValue with empty string

Paul Sandoz-2
Hi Michael,

The only current way i can think of doing this is to write a request  
filter that removes all query parameters that have empty values or no  
values. Obviously this is an all or nothing approach that does not  
understand the semantics of query parameters that can have no value. I  
can send more details on that if you wish.

Paul.

On Oct 20, 2010, at 8:08 PM, Michael Mogley wrote:

> It seems that a parameter passed in with an empty string will not  
> trigger substitution of the default value.  Is it possible to  
> somehow configure Jersey to switch this behavior to perform  
> substitution of the default in such cases?
>
> Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: @DefaultValue with empty string

kenglxn
Hi.
I posted a bug with a patch as proposed fix here: http://java.net/jira/browse/JERSEY-695
Reply | Threaded
Open this post in threaded view
|

Re: @DefaultValue with empty string

Daniel Larsson
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. 
Reply | Threaded
Open this post in threaded view
|

Re: @DefaultValue with empty string

kenglxn
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?

Reply | Threaded
Open this post in threaded view
|

Re: @DefaultValue with empty string

Daniel Larsson
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 <[hidden email]>

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.

Reply | Threaded
Open this post in threaded view
|

Re: @DefaultValue with empty string

kenglxn
Daniel Larsson wrote
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.
I agree.
For non-primitive types you actually get through to the resource.

The issue is only relevant for primitive types that fail in the valueOf call.
Perhaps this empty field check could be conditionally invoked only if the value is a primitive type?