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
