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 >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
