users@jersey.java.net

Re: [Jersey] Example 2.13: Custom Java type for consuming header/request parameters

From: Paul Sandoz <Paul.Sandoz_at_oracle.com>
Date: Tue, 5 Oct 2010 12:50:07 +0200

On Oct 4, 2010, at 8:40 PM, Olson, Dan (LNG-CSP) wrote:

> Hi,
>
> When using a custom class type for parameters and the specified
> parameter name used in @HeaderParam or @QueryParam does not exist it
> the parameter value is null. It seems that the custom class is not
> given the opportunity to process an empty string (or null) as input;
> construction is completely bypassed in favor of a null value.
>

Not currently, can you log an issue, it may be possible to support
this using a:

   https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/spi/StringReaderProvider.html

if appropriate annotated to support null values. We already do a
similar trick to stop aggressive processing of @DefaultValue values,
see:

   https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/spi/StringReader.ValidateDefaultValue.html

Or support an annotation on the parameter itself.

Can you log an enhancement?

Paul.

> Can this behavior be modified or otherwise handled so that the
> custom class can take action? One workaround is to use @DefaultValue
> to provide a non-null value. Unfortunately that clutters the
> solution somewhat.
>
> Your thoughts would be appreciated.
>
> Regards,
>
> Dan