What about this: http://cxf.apache.org/docs/jax-rs-filters.html#JAX-RSFilters-OverridingrequestURI%2Cqueryandheaders
The only thing I don't like about not returning Response objects is it doesn't let the method set HTTP specific stuff. Which just means we need really really good filters. For example, a create should set the Location HTTP header field with the proper URL to the newly created object. On Wed, Jul 24, 2013 at 9:21 AM, Erin Noe-Payne <[email protected]>wrote: > Ok, I'm having trouble setting up filters that are able to access > query string parameters to do pagination. I've submitted a review > request [1] with my work so far (look at pages, categories, and the > filters). My plan was the following workflow - > > - Request is received and processed by the controller. Controller > returns an object <T> or List<T> (Page, Category, etc). For any list > resource it gets all entities, and allows the pagination filter to > subset. > - JsonWrapperResponseFilter process the request and wraps the data > object in the wrapper object > - PaginationResponseFilter checks if the data object is a list. It > retrieves the values of limit and offset QS parameters or sets them to > defaults. It then subsets the data and sets appropriate meta fields in > the json object. > > The issue is that the response handler does not give me access (as far > as I can tell) to the query string values. Which makes me think I'm > missing something, or that this is the wrong way to approach the > problem. Any help or input is appreciated. > > > [1] https://reviews.apache.org/r/12901/ > > On Tue, Jul 23, 2013 at 3:08 PM, Chris Geer <[email protected]> wrote: > > Good point...I forgot Rave is using CXF 2.7.x which includes that new > > stuff. That would be a better choice, plus it wouldn't tie us to CXF. > > > > > > On Tue, Jul 23, 2013 at 11:54 AM, Erin Noe-Payne > > <[email protected]>wrote: > > > >> Slight update on this journey of discovery - it looks like what we > >> actually want to use is not interceptors, but jaxrs filters. See: > >> http://cxf.apache.org/docs/jax-rs-filters.html > >> > >> On Tue, Jul 23, 2013 at 12:56 PM, Chris Geer <[email protected]> > >> wrote: > >> > On Tue, Jul 23, 2013 at 9:55 AM, Erin Noe-Payne < > >> [email protected]>wrote: > >> > > >> >> On Tue, Jul 23, 2013 at 12:14 PM, Chris Geer <[email protected]> > >> >> wrote: > >> >> > On Mon, Jul 22, 2013 at 9:04 PM, Erin Noe-Payne < > >> >> [email protected]>wrote: > >> >> > > >> >> >> On Mon, Jul 22, 2013 at 11:56 PM, Chris Geer < > [email protected]> > >> >> >> wrote: > >> >> >> > On Mon, Jul 22, 2013 at 12:58 PM, Erin Noe-Payne > >> >> >> > <[email protected]>wrote: > >> >> >> > > >> >> >> >> - Simple solution: All rest response models are flat. We ignore > >> any > >> >> >> >> nested data, and just have separate endpoints to deliver that > >> data. > >> >> >> >> I.E. Every model in the org.apache.rave.rest.model package has > >> only > >> >> >> >> properties of "primitive" types, with no lists, no other > classes. > >> >> That > >> >> >> >> is NOT currently the case. Then the fields interceptor checks > for > >> the > >> >> >> >> presence of a fields argument. If not present, the object is > >> >> delivered > >> >> >> >> as is. If present the argument (a string) is split by comma and > >> only > >> >> >> >> the matched properties are delivered. The fields qs argument > only > >> has > >> >> >> >> to support comma-delimited list of property names. > >> >> >> >> Ex: ?fields=name,pageType > >> >> >> >> //returns a page or pages with only name and pageType > properties > >> >> >> >> > >> >> >> > > >> >> >> > I like the simple solution. I think the CRUD part of the API > should > >> >> be as > >> >> >> > flat as possible like Erin suggested and we have "special" end > >> points > >> >> to > >> >> >> > get back hierarchical data when needed, i.e. page rendering. > >> >> >> > > >> >> >> > >> >> >> Just to make sure we are on the same page, my proposal is that in > >> both > >> >> >> cases a get request without any special query string will return > only > >> >> >> flat data. The difference is that in the second case the fields > query > >> >> >> parameter will support a syntax that CAN deliver nested data in a > >> >> >> single request. > >> >> >> > >> >> > > >> >> > That confuses me. I thought the whole point of the "special" end > point > >> >> was > >> >> > to handle things like page rendering in one query which would > require > >> >> > hierarchical data every time. Why force the use of query string > >> params to > >> >> > get that? > >> >> > > >> >> > >> >> I was speaking in reference to the standard endpoints. The > >> >> page(s)ForRender endpoint is a special endpoint that serves a > specific > >> >> client need for a complex nested data set. It will always return > >> >> hierarchical data, will probably not support field selection at all. > >> >> > >> >> The standard endpoints will by default return flat data. They will > >> >> support field selection. If we choose to implement the more complex > >> >> field selection, then they will allow you to request nested data > >> >> through the field selection syntax. > >> >> > >> > > >> > ok > >> > > >> >> > >> >> >> > >> >> >> >> > >> >> >> >> - Complicated solution: All rest response models include > >> references > >> >> to > >> >> >> >> their nested data. This is the currently the case, and can be > >> seen in > >> >> >> >> org.apache.rave.rest.model.Page. The fields interceptor checks > for > >> >> >> >> presence of fields qs argument. If not present it strips all > >> nested > >> >> >> >> data from the models and only returns properties. If it is > >> present, > >> >> it > >> >> >> >> parses the argument and updates the data. The fields argument > >> needs > >> >> to > >> >> >> >> support a more complicated syntax that allows the requesting of > >> >> nested > >> >> >> >> data. I would copy the syntax of facebook's graph search api, > >> which > >> >> >> >> has a pretty readable solution. You allow for .fields and > .limit > >> on > >> >> >> >> fields, which can be nested. > >> >> >> >> Ex: > >> >> >> >> > >> >> >> > >> >> > >> > ?fields=name,pageType,regions.limit(2).fields(regionWidgets.fields(widgetId,locked)) > >> >> >> >> //returns a page or pages with name and pageType properties, > >> nested > >> >> >> >> list of regions (max of 2) with nested list of regionWidgets > with > >> >> only > >> >> >> >> properties of widgetId and locked > >> >> >> >> > >> >> >> >> In all cases, id should always be returned. > >> >> >> >> I think the algorithm in the simple solution is easy. > >> >> >> >> In a sense the algorithm in the second should be simple, > because > >> the > >> >> >> >> service layer is already getting all the nested data, and you > are > >> >> just > >> >> >> >> stripping it off. Not sure what the performance implications of > >> that > >> >> >> >> are though. > >> >> >> >> > >> >> >> >> On Mon, Jul 22, 2013 at 3:40 PM, Chris Geer < > >> [email protected]> > >> >> >> wrote: > >> >> >> >> > On Mon, Jul 22, 2013 at 12:07 PM, Erin Noe-Payne > >> >> >> >> > <[email protected]>wrote: > >> >> >> >> > > >> >> >> >> >> Going back to the discussion on field selection - I am > >> currently > >> >> >> going > >> >> >> >> >> through the exercise of writing out the Resource interfaces > to > >> >> define > >> >> >> >> >> our endpoints. There is a set of generic query string > >> parameters > >> >> >> that > >> >> >> >> >> we wish to support on all or many of the endpoints - fields > >> (any > >> >> get > >> >> >> >> >> request), limit / offset (any get request that returns a > list). > >> >> >> >> >> > >> >> >> >> >> Rather than writing each endpoint to accept QueryParam()'s > and > >> >> repeat > >> >> >> >> >> the appropriate logic, I assume we would want to take > >> advantage of > >> >> >> cxf > >> >> >> >> >> interceptors [1] to intelligently and generically handle > those > >> qs > >> >> >> >> >> arguments? > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > I like the concept but I'm not sure how we generically > filter, > >> >> >> especially > >> >> >> >> > with nested data. I'd love to see it work that way though. > >> >> >> Interceptors > >> >> >> >> are > >> >> >> >> > pretty easy to use, it's the filter algorithm I haven't > figured > >> out > >> >> >> yet. > >> >> >> >> > Thoughts? > >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> [1] http://cxf.apache.org/docs/interceptors.html > >> >> >> >> >> > >> >> >> >> >> On Mon, Jul 22, 2013 at 11:40 AM, Erin Noe-Payne > >> >> >> >> >> <[email protected]> wrote: > >> >> >> >> >> > Ok, so the endpoint is now working. Any thoughts about the > >> >> >> >> >> > JsonResponseWrapper approach? Does that seem like the best > >> way > >> >> to > >> >> >> get > >> >> >> >> >> > wrapped responses? > >> >> >> >> >> > > >> >> >> >> >> > For the next step I would like to start writing out all of > >> the > >> >> >> >> >> > resource interfaces so that we can begin writing angular > >> >> $resource > >> >> >> >> >> > services against them. > >> >> >> >> >> > > >> >> >> >> >> > On Sun, Jul 21, 2013 at 8:54 PM, Erin Noe-Payne > >> >> >> >> >> > <[email protected]> wrote: > >> >> >> >> >> >> Awesome, thanks Chris. Not sure I would have ever figured > >> that > >> >> one > >> >> >> >> >> out... > >> >> >> >> >> >> > >> >> >> >> >> >> On Sun, Jul 21, 2013 at 3:59 PM, Chris Geer < > >> >> >> [email protected]> > >> >> >> >> >> wrote: > >> >> >> >> >> >>> Erin, > >> >> >> >> >> >>> > >> >> >> >> >> >>> I got it working, at least the CXF part. Couple things: > >> >> >> >> >> >>> > >> >> >> >> >> >>> 1) In the interface, make sure to annotate the @GET > methods > >> >> >> >> >> >>> 2) In your DefaultRegionWidgetsResource class, remove > the > >> >> >> @ParamPath > >> >> >> >> >> >>> attributes from variable signatures. I know Intellij > puts > >> >> those > >> >> >> in > >> >> >> >> >> there > >> >> >> >> >> >>> but they cause problems. Only the interface should be > >> >> annotated. > >> >> >> >> >> >>> > >> >> >> >> >> >>> Chris > >> >> >> >> >> >>> > >> >> >> >> >> >>> > >> >> >> >> >> >>> On Sat, Jul 20, 2013 at 2:00 PM, Erin Noe-Payne < > >> >> >> >> >> [email protected]>wrote: > >> >> >> >> >> >>> > >> >> >> >> >> >>>> Review board is not accepting my patch and is not > >> accepting > >> >> the > >> >> >> >> valid > >> >> >> >> >> >>>> file paths. I have attached the patch as a file to the > >> >> review. > >> >> >> >> >> >>>> > >> >> >> >> >> >>>> On Sat, Jul 20, 2013 at 4:40 PM, Chris Geer < > >> >> >> [email protected] > >> >> >> >> > > >> >> >> >> >> wrote: > >> >> >> >> >> >>>> > Erin, I'm not seeing a patch posted up there. > >> >> >> >> >> >>>> > > >> >> >> >> >> >>>> > > >> >> >> >> >> >>>> > On Fri, Jul 19, 2013 at 2:27 PM, Erin Noe-Payne < > >> >> >> >> >> >>>> [email protected]>wrote: > >> >> >> >> >> >>>> > > >> >> >> >> >> >>>> >> I was never able to hit the endpoint as expected. > I've > >> >> posted > >> >> >> >> the > >> >> >> >> >> >>>> >> patch on the review board if anyone can take a look > and > >> >> offer > >> >> >> >> >> advice - > >> >> >> >> >> >>>> >> https://reviews.apache.org/r/12777/. > >> >> >> >> >> >>>> >> > >> >> >> >> >> >>>> >> Thanks > >> >> >> >> >> >>>> >> > >> >> >> >> >> >>>> >> On Fri, Jul 19, 2013 at 2:41 PM, Chris Geer < > >> >> >> >> [email protected] > >> >> >> >> >> > > >> >> >> >> >> >>>> wrote: > >> >> >> >> >> >>>> >> > On Friday, July 19, 2013, Erin Noe-Payne wrote: > >> >> >> >> >> >>>> >> > > >> >> >> >> >> >>>> >> >> On Fri, Jul 19, 2013 at 1:24 PM, Chris Geer < > >> >> >> >> >> [email protected] > >> >> >> >> >> >>>> >> <javascript:;>> > >> >> >> >> >> >>>> >> >> wrote: > >> >> >> >> >> >>>> >> >> > In the xml file you need to create the bean, > then > >> >> >> reference > >> >> >> >> >> it in > >> >> >> >> >> >>>> the > >> >> >> >> >> >>>> >> >> > server element near the top. Other than > that...no, > >> >> that > >> >> >> >> >> should be > >> >> >> >> >> >>>> >> all. I > >> >> >> >> >> >>>> >> >> > assume you set the Path attribute on the > resource. > >> >> >> >> >> >>>> >> >> > > >> >> >> >> >> >>>> >> >> I did. I'm also messing around with the service > >> >> injection, > >> >> >> >> >> which may > >> >> >> >> >> >>>> >> >> be the issue. Haven't gotten it to work yet > though. > >> >> >> >> >> >>>> >> >> > >> >> >> >> >> >>>> >> >> > I thought we were going to do > >> >> >> >> >> >>>> >> pages/<id>/regions/<id>/regionwidgets/<id> > >> >> >> >> >> >>>> >> >> > since it makes no sense to manage a region > widget > >> >> >> outside a > >> >> >> >> >> region > >> >> >> >> >> >>>> >> >> outside > >> >> >> >> >> >>>> >> >> > a page? > >> >> >> >> >> >>>> >> >> Possibly. Right now I'm just trying to do a > proof > >> of > >> >> >> concept > >> >> >> >> >> with > >> >> >> >> >> >>>> the > >> >> >> >> >> >>>> >> >> wrapped json object so I picked something simple > >> with > >> >> the > >> >> >> >> >> service and > >> >> >> >> >> >>>> >> >> rest models already in place. > >> >> >> >> >> >>>> >> >> > >> >> >> >> >> >>>> >> >> In general though I don't see any value to > dealing > >> with > >> >> >> >> region > >> >> >> >> >> >>>> widgets > >> >> >> >> >> >>>> >> >> as a nested resource (pages/:id/regions/:id...) > over > >> >> just > >> >> >> >> >> dealing > >> >> >> >> >> >>>> with > >> >> >> >> >> >>>> >> >> them directly. It's just adding weight to the > pages > >> >> >> >> controller, > >> >> >> >> >> >>>> rather > >> >> >> >> >> >>>> >> >> than breaking them up and dealing with resource > >> >> concerns > >> >> >> >> >> separately. > >> >> >> >> >> >>>> >> >> > >> >> >> >> >> >>>> >> >> I get what you're saying about regions and > >> >> regionwidgets > >> >> >> only > >> >> >> >> >> making > >> >> >> >> >> >>>> >> >> sense in the context of a page, but you could say > >> the > >> >> same > >> >> >> >> >> thing for > >> >> >> >> >> >>>> >> >> any 1-many associated resource. Both entities are > >> >> always > >> >> >> >> >> uniquely > >> >> >> >> >> >>>> >> >> identified, so why not deal with them > individually? > >> I > >> >> see > >> >> >> an > >> >> >> >> >> upside > >> >> >> >> >> >>>> of > >> >> >> >> >> >>>> >> >> simpler code, consistent api endpoints, and I > see no > >> >> >> >> downside. > >> >> >> >> >> >>>> >> > > >> >> >> >> >> >>>> >> > > >> >> >> >> >> >>>> >> > Honestly, my hope is that someday they aren't > >> uniquely > >> >> >> >> >> identified and > >> >> >> >> >> >>>> are > >> >> >> >> >> >>>> >> > really sun objects unlike JPA today. But that is a > >> >> longer > >> >> >> >> >> >>>> conversation. > >> >> >> >> >> >>>> >> > > >> >> >> >> >> >>>> >> >> > >> >> >> >> >> >>>> >> >> > > >> >> >> >> >> >>>> >> >> > > >> >> >> >> >> >>>> >> >> > On Fri, Jul 19, 2013 at 10:16 AM, Erin > Noe-Payne > >> >> >> >> >> >>>> >> >> > <[email protected]>wrote: > >> >> >> >> >> >>>> >> >> > > >> >> >> >> >> >>>> >> >> >> I'm trying to register a new endpoint for > >> >> >> regionWidgets. > >> >> >> >> I've > >> >> >> >> >> >>>> added > >> >> >> >> >> >>>> >> >> >> the interface and default implementation, and > >> >> created / > >> >> >> >> >> registered > >> >> >> >> >> >>>> >> the > >> >> >> >> >> >>>> >> >> >> bean in cxf-applicationContext.xml. > >> >> >> >> >> >>>> >> >> >> > >> >> >> >> >> >>>> >> >> >> However, when I hit the endpoint I get an > error: > >> >> >> >> >> >>>> >> >> >> [INFO] [talledLocalContainer] WARN : > >> >> >> >> >> >>>> >> >> >> org.apache.cxf.jaxrs.utils.JAXRSUtils - No > >> operation > >> >> >> >> matching > >> >> >> >> >> >>>> request > >> >> >> >> >> >>>> >> >> >> path "/portal/api/rest/regionWidgets/1" is > found, > >> >> >> Relative > >> >> >> >> >> Path: > >> >> >> >> >> >>>> /1, > >> >> >> >> >> >>>> >> >> >> HTTP Method: GET, ContentType: */*, Accept: > >> >> >> >> >> >>>> >> >> >> > >> >> >> >> >> > >> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,. > >> >> >> >> >> >>>> >> >> >> Please enable FINE/TRACE log level for more > >> details. > >> >> >> >> >> >>>> >> >> >> > >> >> >> >> >> >>>> >> >> >> Is there anything else I need to do in order > to > >> >> create > >> >> >> and > >> >> >> >> >> >>>> register a > >> >> >> >> >> >>>> >> >> >> new endpoint? > >> >> >> >> >> >>>> >> >> >> > >> >> >> >> >> >>>> >> >> >> On Tue, Jul 16, 2013 at 11:53 PM, Erin > Noe-Payne > >> >> >> >> >> >>>> >> >> >> <[email protected]> wrote: > >> >> >> >> >> >>>> >> >> >> > On Tue, Jul 16, 2013 at 10:24 PM, Chris > Geer < > >> >> >> >> >> >>>> >> [email protected]> > >> >> >> >> >> >>>> >> >> >> wrote: > >> >> >> >> >> >>>> >> >> >> >> On Tue, Jul 16, 2013 at 7:04 PM, Erin > >> Noe-Payne < > >> >> >> >> >> >>>> >> >> >> [email protected]>wrote: > >> >> >> >> >> >>>> >> >> >> >> > >> >> >> >> >> >>>> >> >> >> >>> On Tue, Jul 16, 2013 at 9:20 PM, Matt > >> Franklin < > >> >> >> >> >> >>>> >> >> >> [email protected]> > >> >> >> >> >> >>>> >> >> >> >>> wrote: > >> >> >> >> >> >>>> >> >> >> >>> > On Tue, Jul 16, 2013 at 12:53 PM, Chris > >> Geer < > >> >> >> >> >> >>>> >> >> [email protected]> > >> >> >> >> >> >>>> >> >> >> >>> wrote: > >> >> >> >> >> >>>> >> >> >> >>> > > >> >> >> >> >> >>>> >> >> >> >>> >> On Tue, Jul 16, 2013 at 10:32 AM, Erin > >> >> Noe-Payne > >> >> >> >> >> >>>> >> >> >> >>> >> <[email protected]>wrote: > >> >> >> >> >> >>>> >> >> >> >>> >> > >> >> >> >> >> >>>> >> >> >> >>> >> > Any further discussion here? I would > >> like > >> >> to > >> >> >> >> start > >> >> >> >> >> >>>> >> implementing > >> >> >> >> >> >>>> >> >> >> more > >> >> >> >> >> >>>> >> >> >> >>> >> > of the REST APIs, as it is > foundational > >> for > >> >> >> the > >> >> >> >> >> entire > >> >> >> >> >> >>>> >> angular > >> >> >> >> >> >>>> >> >> >> >>> >> > architecture. > >> >> >> >> >> >>>> >> >> >> >>> >> > > >> >> >> >> >> >>>> >> >> >> >>> >> > My understanding from Matt is that > the > >> >> current > >> >> >> >> apis > >> >> >> >> >> in > >> >> >> >> >> >>>> trunk > >> >> >> >> >> >>>> >> >> are > >> >> >> >> >> >>>> >> >> >> >>> >> > mostly proof of concept - they are > not > >> >> tested > >> >> >> and > >> >> >> >> >> much of > >> >> >> >> >> >>>> >> the > >> >> >> >> >> >>>> >> >> >> >>> >> > functionality is just stubbed. Are > any > >> of > >> >> the > >> >> >> >> rest > >> >> >> >> >> api > >> >> >> >> >> >>>> >> >> >> implementations > >> >> >> >> >> >>>> >> >> >> >>> >> > in the code base a good working > >> example? Is > >> >> >> there > >> >> >> >> >> other > >> >> >> >> >> >>>> >> >> >> documentation > >> >> >> >> >> >>>> >> >> >> >>> >> > we can reference? > >> >> >> >> >> >>>> >> >> >> >>> >> > > >> >> >> >> >> >>>> >> >> >> >>> >> > >> >> >> >> >> >>>> >> >> >> >>> >> I've been working on the People > resource > >> as a > >> >> >> >> >> "reference" > >> >> >> >> >> >>>> of > >> >> >> >> >> >>>> >> how > >> >> >> >> >> >>>> >> >> I'd > >> >> >> >> >> >>>> >> >> >> >>> like > >> >> >> >> >> >>>> >> >> >> >>> >> to see them done but it's still a work > in > >> >> >> >> progress. I > >> >> >> >> >> need > >> >> >> >> >> >>>> to > >> >> >> >> >> >>>> >> go > >> >> >> >> >> >>>> >> >> >> back > >> >> >> >> >> >>>> >> >> >> >>> and > >> >> >> >> >> >>>> >> >> >> >>> >> pull out the JSONView stuff and > >> reimplement > >> >> the > >> >> >> >> >> "fields" > >> >> >> >> >> >>>> >> concept. > >> >> >> >> >> >>>> >> >> >> >>> Couple of > >> >> >> >> >> >>>> >> >> >> >>> >> notes: > >> >> >> >> >> >>>> >> >> >> >>> >> > >> >> >> >> >> >>>> >> >> >> >>> >> - Object representations should be as > >> flat > >> >> as > >> >> >> >> >> possible > >> >> >> >> >> >>>> >> >> >> >>> >> and separate requests should be made to > >> >> nested > >> >> >> >> >> resources to > >> >> >> >> >> >>>> >> get > >> >> >> >> >> >>>> >> >> >> nested > >> >> >> >> >> >>>> >> >> >> >>> >> details (i.e. if you have regions and > >> >> >> >> >> >>>> regions/1/regionwidgets, > >> >> >> >> >> >>>> >> >> the > >> >> >> >> >> >>>> >> >> >> >>> regions > >> >> >> >> >> >>>> >> >> >> >>> >> representation should not contain an > >> array of > >> >> >> >> >> >>>> regionwidgets) > >> >> >> >> >> >>>> >> >> >> >>> >> > >> >> >> >> >> >>>> >> >> >> >>> > > >> >> >> >> >> >>>> >> >> >> >>> > I am concerned about the round trips to > >> >> support > >> >> >> this > >> >> >> >> >> when > >> >> >> >> >> >>>> >> >> rendering > >> >> >> >> >> >>>> >> >> >> the > >> >> >> >> >> >>>> >> >> >> >>> > page. With any page that has a > sufficient > >> >> >> number of > >> >> >> >> >> >>>> gadgets, > >> >> >> >> >> >>>> >> >> adding > >> >> >> >> >> >>>> >> >> >> to > >> >> >> >> >> >>>> >> >> >> >>> the > >> >> >> >> >> >>>> >> >> >> >>> > number of requests becomes problematic. > >> >> >> >> >> >>>> >> >> >> >>> > > >> >> >> >> >> >>>> >> >> >> >>> > >> >> >> >> >> >>>> >> >> >> >>> I see that rule applying to the "standard" > >> rest > >> >> >> >> >> endpoints for > >> >> >> >> >> >>>> >> crud > >> >> >> >> >> >>>> >> >> >> >>> operations on resources. We > >> >> >> >> >> >>>> >> > >> >> >> >> >> >>>> > >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> >
