Sorry, should be <jaxrs:server address="/jsonp"> <jaxrs:serviceBeans> <ref bean="controller"/> </jaxrs:serviceBeans> </jaxrs:server>
See also [1] https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+Data+Bindings#JAX-RSDataBindings-JSONWithPadding Cheers, Sergey On Sat, Apr 9, 2011 at 4:24 PM, Sergey Beryozkin <[email protected]>wrote: > Forgot to answer to this question: > >> >> >> >> On a side note, is it possible to define two jaxrs:server elements in my >> Spring context, with a different root path, different interceptors, but the >> same controller beans? If I wanted this interceptor to only be used for >> JSONP calls, I could have them use a different root path, and the regular >> path wouldn’t have to go through the interceptor. >> >> > Sure, you can do it, just declare your controller as a standalone bean and > then refer to it from multiple endpoints. > <jaxrs:server address="/jsonp"> <ref bean="controller"/> > <jaxrs:server address="/json"> <ref bean="controller"/> > > <bean id="congtroller" class="MyController.class"/> > > Cheers, Sergey > > >> >> >> *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? >> >> >> >> >> > > > >
