Hi Thierry, I’am also a friend of a more framework like approach, at least as a service developer. And your ideas with using Java annotations sounds also nice and promising (and remember me a little bit at the Java annotation PoC in Olingo v2 and OLINGO-129). But I also think that for Olingo 4.0 and the first stable core release focus should be on implementation of OData Version 4 specification in a more library point of view. Afterwards if the library is stable and supports the main OData 4 specification aspects the next steps could be to do more for the convenience of a service developer with frameworks on top of the library (e.g. JPA and Java-Annotation extensions in Olingo V2). But this is just my current opinion and focus and I will not prevent anybody in the community to start with a framework around of Olingo. Quite to the contrary, I think it's good when proof of concepts and/or frameworks already are started ;o)
Back to OLINGO-573 I think we should check if the processor design is an approach which should/could be merged into the core (or replace actual design) or if it is the better way to see it as a framework/extension which resides on top or beside the core library. Because at least with the next „beta-03“ release we should be stable with the API (just smaller changes but not a greater redesign). And for your questions, for me it is ok to discuss/comment in the issue. So feel free to put your mail in OLINGO-537. And the TripPin service is implemented in the „TripPinHandler“ and „TripPinServlet“ classes within the test module (packages), so you have already found it ;o) Kind regards, Michael > On 20 Feb 2015, at 11:45, Thierry Templier <[email protected]> wrote: > > 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
