What parts of this are "standard" in JAX-RS? I imagine the "extensionMappings" and "languageMappings" are, but not the "_type" parameter?
From: Sergey Beryozkin [mailto:[email protected]] Sent: Tuesday, April 12, 2011 8:24 AM To: KARR, DAVID (ATTSI) Cc: [email protected] Subject: Re: Handling "Accept" and "Accept-Language" in query parameters Hi Perhaps JsonpInInterceptor [1] can be extended ? If you think it will help then may be you can submit a small patch ? But see also [2], you can use extension and language mappings to override Accept and Accept-Language Cheers, Sergey [1] http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/jsonp/JsonpInInterceptor.java [2] https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS#JAX-RS-Debugging On Tue, Apr 12, 2011 at 4:54 AM, KARR, DAVID (ATTSI) <[email protected]<mailto:[email protected]>> wrote: It was straightforward for me to write an additional interceptor to translate specific query params to headers (A list property defined in Spring specifies the list of parameter names to check for). Is this basically what you meant by that? Seems like this is something that should be a reusable component. From: Sergey Beryozkin [mailto:[email protected]<mailto:[email protected]>] Sent: Friday, April 08, 2011 10:20 AM To: KARR, DAVID (ATTSI) Cc: [email protected]<mailto:[email protected]> Subject: Re: Handling "Accept" and "Accept-Language" in query parameters Hi Yes, it looks like a good idea. I'm also going to commit a JSONP patch shortly, and you will be able to extend the inbound interceptor and update the Message headers as needed. Message.QUERY_STRING key references the query itself, "HTTP_REQUEST" - HttpServletRequest (you can check parameters or queries), Message.PROTOCOL_HEADERS - the map of headers Thanks, Sergey On Fri, Apr 8, 2011 at 4:16 PM, KARR, DAVID (ATTSI) <[email protected]<mailto:[email protected]>> wrote: Just so it's clear, I'm talking about the fact that the "Accept" header, or any other HTTP header, cannot be sent from a "script" block. The only choice we would have would be to send query/request parameters. I'm trying to figure out the cleanest way to enable use of query parameters for functions usually specified by headers, without changing my controller, which specifies the use of HTTP headers. My current thought is to have an interceptor check for specific query parameters, perhaps in a configurable map, and translate those to HTTP headers, and hopefully this can be done before CXF makes decisions based on the presence of particular HTTP headers. From: Sergey Beryozkin [mailto:[email protected]<mailto:[email protected]>] Sent: Friday, April 08, 2011 3:44 AM To: KARR, DAVID (ATTSI) Cc: [email protected]<mailto:[email protected]> Subject: Re: Handling "Accept" and "Accept-Language" in query parameters Hi David I think I have to apply the JSONP patch that we have asap :-), and catch up a bit with the way JSONP works. I'm still not sure I follow, basically, looks like you'd like to have some utility code available that can say take the value of Accept header and return a sorted list, yes ? If no then please post an example with some pseudo code showing what are the actual expectations Cheers, Sergey On Thu, Apr 7, 2011 at 11:27 PM, KARR, DAVID (ATTSI) <[email protected]<mailto:[email protected]>> wrote: Perhaps I wasn't clear. The app currently checks for certain header parameters, along with some query parameters. In order to be fully usable from JSONP script tags, I'll have to get it to work by using query parameters for what I'm currently using header parameters for. As to a format of the query parameters, that doesn't particularly matter. If it's more workable to have a bunch of former header parameters embedded into a single query parameter somehow, I suppose that could work, if there was some reason that was more convenient than individual query parameters. From: Sergey Beryozkin [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, April 07, 2011 2:57 PM To: [email protected]<mailto:[email protected]> Cc: KARR, DAVID (ATTSI) Subject: Re: Handling "Accept" and "Accept-Language" in query parameters Hi Can you explain a bit more how it works. Do you have individual query parameters representing individual HTTP headers in this case ? Can you post a simple example ? Cheers, Sergey On Thu, Apr 7, 2011 at 10:45 PM, KARR, DAVID (ATTSI) <[email protected]<mailto:[email protected]>> wrote: My CXF JAX-RS app currently looks at a couple of "standard" HTTP headers, being "Accept" and "Accept-Language". It also uses a custom HTTP header. It's come to my attention that we need to examine whether we can support being called from a "script" tag, to support JSONP callbacks. This will not allow changing HTTP headers. I can easily enough change my code to check for my custom header as a query parameter instead of an HTTP header, but the situation isn't as simple for "Accept" and "Accept-Language", which are processed implicitly by CXF. Presently handling of "Accept" is done without any effort on my part, except for perhaps the "@Produces" annotation. Handling of "Accept-Language" is done with almost as little effort, requiring me to call the "HttpHeaders.getAcceptableLanguages()" function. What are some reasonable strategies for getting this information (and using it, more importantly) from request parameters instead? -- Sergey Beryozkin Application Integration Division of Talend<http://www.talend.com> http://sberyozkin.blogspot.com
