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