On Thu, Aug 1, 2013 at 11:32 AM, Chris Geer <[email protected]> wrote: > On Wed, Jul 31, 2013 at 11:19 AM, Erin Noe-Payne > <[email protected]>wrote: > >> On Mon, Jul 29, 2013 at 9:59 AM, Erin Noe-Payne >> <[email protected]> wrote: >> > On Mon, Jul 29, 2013 at 1:54 AM, Chris Geer <[email protected]> >> wrote: >> >> On Thu, Jul 25, 2013 at 11:12 AM, Erin Noe-Payne >> >> <[email protected]>wrote: >> >> >> >>> I'm not entirely sure how to proceed at the moment. For now I will >> >>> start work at the repository layer and try to implement consistent >> >>> crud operations to support the REST api. >> >>> >> >> >> >> Erin, on the CXF 2.7 migration page I saw this. >> >> >> >> >> >> - org.apache.cxf.jaxrs.ext.RequestHandler and >> >> org.apache.cxf.jaxrs.ext.ResponseHandler (use >> >> javax.ws.rs.container.ContainerRequestFilter and >> >> javax.ws.rs.container.ContainerResponseFilter instead). >> >> >> > Thanks Chris, I'll take a look. >> > >> >> It looks like ContainerRequestFilter / ContainerResponseFilter do give >> me access to valid request and response context objects that I can act >> upon. So these are the interfaces we will want to use for setting up >> filters. >> >> Also based on some more reading of CXF docs, it looks to me like we >> can use sub-resource locators [1] as an approach for breaking apart >> the page / region / regionWidget controllers while still using the >> /pages/:id/regions/:id/regionWidgets/:id url paths. >> >> I have submitted a patch on the review board [2] with a partial >> implementation (RB is again preventing me from uploading the patch >> directly so it is an attachment on the review). Look at the resolution >> from PagesResource to RegionsResource. If there are no complaints I am >> going to move forward with this approach. >> >> [1] >> http://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-Subresourcelocators >> . >> [2] https://reviews.apache.org/r/13119/ > > > Erin, > > On your RegionWidgetsResource, wouldn't you want the class level path to be > @Path("/pages/{pageId}/regions/{regionsId}/regionWidgets") > > If you have it with just @Path("/pages") it doesn't really nest the > regionWidgets under the correct page. >
Good catch, thank you. I actually do not want a @Path annotation at the class level at all. I want RegionWidgetsResource to be a dynamically resolved subresource. It will be only accessible via the RegionsResource "getRegionWidgetsResource" method, which is in turn only accessible via PeopleResource's "getRegionsResource". >> >> >> >> >> >> So, it looks like the docs are a little out of date. The >> >> ContainerResponseFilter handler method gets two params, Request Context >> and >> >> Response Context. That might give you what you need. I haven't played >> with >> >> it yet but it's worth a look. >> >> >> >> Chris >> >> >> >> >> >> >> >>> On Wed, Jul 24, 2013 at 1:59 PM, Erin Noe-Payne >> >>> <[email protected]> wrote: >> >>> > On Wed, Jul 24, 2013 at 1:37 PM, Chris Geer <[email protected]> >> >>> wrote: >> >>> >> What about this: >> >>> >> >> >>> >> >> >>> >> http://cxf.apache.org/docs/jax-rs-filters.html#JAX-RSFilters-OverridingrequestURI%2Cqueryandheaders >> >>> >> >> >>> > >> >>> > This is referring to a RequestHandler, not a ResponseHandler. In the >> >>> > request handler the Message object does have correct request uri >> data, >> >>> > etc, but I don't have access to the Response object yet. >> >>> > >> >>> >> 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. >> >>> >> >> >>> > >> >>> > That's fair. And the controllers could return response objects and >> >>> > following filters could just iteratively return >> >>> > Response.fromResponse(). But if we take a step back from filters or >> >>> > interceptors or whatever implementation approach, here's the problem >> >>> > I'm trying to solve: >> >>> > >> >>> > Taking your Location header example - all requests to get or create >> an >> >>> > entity should have the location header set to the canonical url of >> the >> >>> > resource. Post requests creating a new resource should have a >> location >> >>> > header pointing to the newly created resource. That is universally >> >>> > true, and I should be able to write that code generically. I do not >> >>> > want to have to set the location header in every controller for every >> >>> > resource that handles the @POST method. That seems like it should be >> >>> > doable, and filters or interceptors seemed like the way to do it. Now >> >>> > I'm not so sure. >> >>> > >> >>> > So is that a goal worth pursuing, and if yes what is the right >> approach? >> >>> > >> >>> >> >> >>> >> 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 >> >>> >>> >> >> >> >> >> >>>> >> >> >>> >>> >> >> >> >> >> >>>> >> >>> >>> >> >> >> >> >> >> >>> >>> >> >> >> >> >> >>> >>> >> >> >> >> >>> >>> >> >> >> >>> >>> >> >> >>> >>> >> >>> >>
