Are you referring to JSONP-related patch ? It was applied to 2.3.4/2.4.0, see
https://issues.apache.org/jira/browse/CXF-3005, SubversionCommits tab for more info. Cheers, Sergey On Mon, Apr 18, 2011 at 4:53 PM, KARR, DAVID (ATTSI) <[email protected]> wrote: > Was this patch part of release 2.4.0? if not, is there a particular > issue number I can track for this? > > > > *From:* Sergey Beryozkin [mailto:[email protected]] > *Sent:* Tuesday, April 12, 2011 12:53 PM > *To:* KARR, DAVID (ATTSI) > *Cc:* [email protected] > *Subject:* Re: Handling "Accept" and "Accept-Language" in query parameters > > > > No, JsonpInInterceptor, with two out interceptors are utility interceptors > that have been added to the trunk as part of the patch. > Re your other questions, you can do > > /resource.xml.en > > and that will override both Accept and Accept-Language, provided mappings > are available. > > I don't recall now, it was probably part of JAX-RS 0.8, for some reasons it > did not make it into the final spec, not sure why > > Cheers, Sergey > > On Tue, Apr 12, 2011 at 5:25 PM, KARR, DAVID (ATTSI) <[email protected]> > wrote: > > Concerning the “JsonpInInterceptor”, is this the class that you have a > pending patch for? Assuming that’s true, what is the issue that’s addressed > by the patch? > > > > *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]> > 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]] > *Sent:* Friday, April 08, 2011 10:20 AM > *To:* KARR, DAVID (ATTSI) > *Cc:* [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]> > 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]] > > *Sent:* Friday, April 08, 2011 3:44 AM > *To:* KARR, DAVID (ATTSI) > *Cc:* [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]> > 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]] > *Sent:* Thursday, April 07, 2011 2:57 PM > *To:* [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]> > 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 > > > > >
