I will reply my comment on the JIRA, but here is where you can find the code for TripPin
https://github.com/apache/olingo-odata4/tree/olingo-server-extension/lib/server-core-ext/src/test/java/org/apache/olingo/server/core Ramesh.. ----- Original Message ----- > The message displaying is really bad. Do you want to put it as a comment in > the issue OLINGO-573. > > Thierry ______________________________________________ > -- Take a look at my blog: http://templth.wordpress.com/ > > Le Vendredi 20 février 2015 11h45, Thierry Templier <[email protected]> a > écrit : > > > Hi Michael and Ramesh, > I definitively love such approach. It's clear that we need to use some > "plumbing code" to implement OData applications with Olingo. I agree and > also think that most of them can be integrated in Olingo itself and not use > directly by the service developer. Having such processor interfaces (the > Ramesh's ones below) are really valuable and are in the spirit of a > framework approach rather than a library one. I think that we don't need in > most cases to work on OData request and response objects of Olingo. This > will contribute to reduce the amount of code and the complexity of > processors. > EntitySet readEntitySet(EdmEntitySet es, UriInfoResource uriInfo)EntitySet > readEntitySet(EdmFunction ef, UriInfoResource uriInfo)long > readCount(EdmEntitySet es, UriInfoResource uriInfo) > > However I wonder if we could go a bit further than static interfaces. Some > frameworks (like Spring MVC / REST) leverages an approach where the method > signatures to handle requests aren't static. The service developer is free > to choose which parameters he wants to have. Such methods are defined and > configured using annotations. I find this approach very valuable, flexible, > convenient and efficient since it allows to get the hints you need very > easy. For example, we can have: > @RequestMapping(method = RequestMethod.GET)public Map<String, Appointment> > get() { (...) } > @RequestMapping(value="/{day}", method = RequestMethod.GET)public Map<String, > Appointment> getForDay(@PathVariable @DateTimeFormat(iso=ISO.DATE) Date day, > Model model) { (...) } > @RequestMapping(method = RequestMethod.POST)public String add(@Valid > AppointmentForm appointment, BindingResult result) { (...) } > In the context of OData / Olingo, we could have something like that to > implement processors. > @Processorpublic class MyProcessor { > @ProcessorMethod(type = ProcessorMethodKind.READ_ENTITY_SET) > public EntitySet readEntitySet(EdmEntitySet es, UriInfoResource uriInfo) > { (...) } > @ProcessorMethod(type = ProcessorMethodKind.READ_ENTITY_SET) public > EntitySet readEntitySet(EdmEntitySet es, ODataRequest request) { (...) } > @ProcessorMethod(type = ProcessorMethodKind.READ_ENTITY) public Entity > readEntity(EdmEntitySet es, @KeyPredicates List<URIParameter> keys) { > (...) } > @ProcessorMethod(type = ProcessorMethodKind.UPDATE_ENTITY) public > Entity updateEntity(EdmEntitySet es, Entity entity, @KeyPredicates > List<URIParameter> keys, HttpMethod method) { boolean partial = > request.getMethod().equals(HttpMethod.PATCH); (...) }} > > This would be a layer upon the classic approach and / or the Ramesh's one. > This also would bring auto-detecting and auto-configuration (based on > annotations) of processors against the OData HTTP handler. > Notice that the field type in the annotation could be easily deduced from the > method signature in most cases. > Otherwise honestly I can't find the TripPin service in the branch > olingo-server-extension: > ./lib/server-core-ext/src/test/java/org/apache/olingo/server/core/TripPinHandler.java > > ./lib/server-core-ext/src/test/java/org/apache/olingo/server/core/TripPinServiceTest.java > > ./lib/server-core-ext/src/test/java/org/apache/olingo/server/core/TripPinServlet.java > > Can you give me more hints to find out this sample? Thanks! > Thierry > >
