cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject Re: JAX-RS @HeaderParam support
Date Mon, 03 Mar 2008 12:23:43 GMT
Hi Barry

I have it implemented in my snapshot, so hopefully, after it's been merged (after I do a backmerge
from your current patch :-)), it will work for you. CXF picks up header values from an underlying
HttpServletRequest. I think it will actually ensure that
when duplicates like this one occues then what you'll get is a "foo : bar,baz"

in a Map<String, List<String>>...

so, if you get a duplicate like this one then a @HeaderParam annotated value will be "bar,baz".
@HttpContext HttpHeaders will also be supported...


> *@HeaderParam The class of the annotated parameter MUST have a constructor
> that accepts a single
> String argument, or a static method named valueOf that accepts a single
> String argument.

At the moment we don't do such checks, but it will need to be done to make CXF JAX-RS more
compliant (for PathParam and MatrixParam as well)

Thanks for looking into it. 

Cheers, Sergey


> Hi all,
> 
> I was thinking of implementing header parameter support. But I just wanted
> to check one thing. What do people think should happen in the case of
> headers being specified multiple times e.g.
> 
> If the below method is invoked with the header for foo set twice. E.g.
> foo=bar and foo=baz
> 
> public Response getUser(@UriParam("id") String id,  @HeaderParam("foo")
> String header) throws Exception {
>        System.out.println("Header is:  " + header);
>        ....
>    }
> 
> The spec says:
> 
> *@HeaderParam The class of the annotated parameter MUST have a constructor
> that accepts a single
> String argument, or a static method named valueOf that accepts a single
> String argument. Other
> types may be supported using a HeaderProvider as described in section 3.2.
> 
> *This seems to suggest we should not be annotating lists etc. to handle
> values specified multiple times. I think we should just use the first one
> found or maybe raise this as an issue with the spec.
> 
> Let me know what you think,
> 
> Barry
>

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message