You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Barry Fitzgerald <ba...@gmail.com> on 2008/03/03 13:07:14 UTC
JAX-RS @HeaderParam support
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
Re: JAX-RS @HeaderParam support
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Barry
Dan has applied the patch so @HeaderParam should work for you.
One thing which is not supported yet is @DefaultValue, so that if no expected header is availbale then some default value is passed in as specified by @DefaultValue (same for QueryParam and yet to be supported MatrixParam). Another thing which is not supported yet is the ability to bind Header/Query params to classes other than Strings (to those which have valueOf() or constructors accepting string). These things are nnot on a critical path, should be simple to fix and we'll support them all eventually, but if it's something you'd expect to work now then perhaps you might want to look into it...
Thanks, Sergey
----- Original Message -----
From: "Sergey Beryozkin" <se...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Monday, March 03, 2008 12:23 PM
Subject: Re: JAX-RS @HeaderParam support
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
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: JAX-RS @HeaderParam support
Posted by Sergey Beryozkin <se...@iona.com>.
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