You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@olingo.apache.org by Ramesh Reddy <ra...@redhat.com> on 2015/02/11 18:29:42 UTC
Re: OLINGO-482
Dear Community,
Based on some discussions on the issue [1], there were several discussions merits of the Processor interface design and how it can be improved for sake of the service developer. Based on those discussions, I have implemented an alternative server side framework as extension. I added this in a separate branch called " olingo-server-extension" , you can also find it at [2]
- This framework currently does not remove any previous Processor interfaces. As extension, these can be evaluated side by side for comparison, then we can decide on the direction best for Olingo in integrating into one module.
- This framework designed specially to make the job of service developer as easy as possible to develop a OData service in the quickest time.
- Tries to enforce the odata specification rules, where they need to be, before service implementer receives the request for processing
- Moves Context URL processing away from service implementer
- Automatically works with registered serializers based on the "Content-Type" defined on the request
- Makes the building of response, based on request, such that it reflects the context of the request. Thus eliminates service implementer violating the spec expectations.
- Provides $metadata schema parser in server side, using which a service implementer can "define" their metadata of the service, rather than current method using the object form.
- Provides a full example based on TripPin service.
I encourage you take look at the example service in the test section of this module and see how a sample service can be developed. We are looking for your comments and suggestions to improve upon this framework and your support of the design to carry forward. Please do reply, even that is either a +1 or -1
I understand that in this new framework, there single interface called "ServiceHandler" for service implementer to develop along with metadata. *If* multiple Processor interfaces is something we really do need, it is fairly straight forward and *easy* to extend the requests to use multiple interfaces as it is currently designed, so that any existing implementations are not broken.
Please take an hour or two looking through this and provide your feedback, and suggestions to improve upon. I sincerely appreciate your time.
[1] https://issues.apache.org/jira/browse/OLINGO-482
[2] https://github.com/apache/olingo-odata4/tree/olingo-server-extension
Thanks.
Ramesh..
http://teiid.org
Re: OLINGO-482
Posted by Ramesh Reddy <ra...@redhat.com>.
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 <te...@yahoo.fr> 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
>
>
Re: OLINGO-482
Posted by Thierry Templier <te...@yahoo.fr>.
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 <te...@yahoo.fr> 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
Re: OLINGO-482
Posted by Thierry Templier <te...@yahoo.fr>.
Thanks very much, Michael!!
Thierry ______________________________________________
-- Take a look at my blog: http://templth.wordpress.com/
Le Lundi 23 février 2015 9h36, "Bolz, Michael" <mi...@sap.com> a écrit :
Hi Thierry,
I also agree that such work like the proposal from Ramesh as well as your’s and hopefully upcoming from the community are really nice and good.
For this we have the open source mindset and approach with Olingo to engage people to contribute and build e.g. frameworks on top of Olingo.
So beside of my focus on core library (and key functions) I will support you on the framework as best as I can ;o)
Kind regards,
Michael
> On 20 Feb 2015, at 19:00, Thierry Templier <te...@yahoo.fr> wrote:
>
> Hi Michael,
> Thanks very much for your answer! I understand well your approach and I agree that the library stability is the most important thing. I think however that it's great that such works like the Ramesh's one to simplify the service developer life are done in parallel by the community. ;-)
> Thierry ______________________________________________
> -- Take a look at my blog: http://templth.wordpress.com/
>
> Le Vendredi 20 février 2015 14h32, mibo <mi...@apache.org> a écrit :
>
>
> 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 <te...@yahoo.fr> 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
>
>
Re: OLINGO-482
Posted by "Bolz, Michael" <mi...@sap.com>.
Hi Thierry,
I also agree that such work like the proposal from Ramesh as well as your’s and hopefully upcoming from the community are really nice and good.
For this we have the open source mindset and approach with Olingo to engage people to contribute and build e.g. frameworks on top of Olingo.
So beside of my focus on core library (and key functions) I will support you on the framework as best as I can ;o)
Kind regards,
Michael
> On 20 Feb 2015, at 19:00, Thierry Templier <te...@yahoo.fr> wrote:
>
> Hi Michael,
> Thanks very much for your answer! I understand well your approach and I agree that the library stability is the most important thing. I think however that it's great that such works like the Ramesh's one to simplify the service developer life are done in parallel by the community. ;-)
> Thierry ______________________________________________
> -- Take a look at my blog: http://templth.wordpress.com/
>
> Le Vendredi 20 février 2015 14h32, mibo <mi...@apache.org> a écrit :
>
>
> 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 <te...@yahoo.fr> 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
>
>
Re: OLINGO-482
Posted by Thierry Templier <te...@yahoo.fr>.
Hi Michael,
Thanks very much for your answer! I understand well your approach and I agree that the library stability is the most important thing. I think however that it's great that such works like the Ramesh's one to simplify the service developer life are done in parallel by the community. ;-)
Thierry ______________________________________________
-- Take a look at my blog: http://templth.wordpress.com/
Le Vendredi 20 février 2015 14h32, mibo <mi...@apache.org> a écrit :
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 <te...@yahoo.fr> 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
Re: OLINGO-482
Posted by mibo <mi...@apache.org>.
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 <te...@yahoo.fr> 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
Re: OLINGO-482
Posted by Thierry Templier <te...@yahoo.fr>.
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
Re: OLINGO-482
Posted by Ramesh Reddy <ra...@redhat.com>.
Any comments?
----- Original Message -----
> Hi all,
> @Ramesh:
> Thanks a lot for your contribution (and push of it into the feature branch).
> I created a separate JIRA issue for this extension feature -> [OLINGO-573](
> https://issues.apache.org/jira/browse/OLINGO-573 )
> As discussed before I can imagine that a more Framework like approach could
> co-exist as separate module in Olingo (and hence a separate JIRA issue seams
> to be a good idea).
> Additionally we could “tag/flag” all commits with e.g. “[OLINGO-573]” to see
> which commits belong to this.
> Then I hope we get some discussion about this approach and find a good
> solution how to integrate it into Olingo.
> Kind regards,
> Michael
> > On 11 Feb 2015, at 18:29, Ramesh Reddy < rareddy@redhat.com > wrote:
>
> > Dear Community,
>
> > Based on some discussions on the issue [1], there were several discussions
> > merits of the Processor interface design and how it can be improved for
> > sake
> > of the service developer. Based on those discussions, I have implemented an
> > alternative server side framework as extension. I added this in a separate
> > branch called " olingo-server-extension" , you can also find it at [2]
>
> > - This framework currently does not remove any previous Processor
> > interfaces.
> > As extension, these can be evaluated side by side for comparison, then we
> > can decide on the direction best for Olingo in integrating into one module.
>
> > - This framework designed specially to make the job of service developer as
> > easy as possible to develop a OData service in the quickest time.
>
> > - Tries to enforce the odata specification rules, where they need to be,
> > before service implementer receives the request for processing
>
> > - Moves Context URL processing away from service implementer
>
> > - Automatically works with registered serializers based on the
> > "Content-Type"
> > defined on the request
>
> > - Makes the building of response, based on request, such that it reflects
> > the
> > context of the request. Thus eliminates service implementer violating the
> > spec expectations.
>
> > - Provides $metadata schema parser in server side, using which a service
> > implementer can "define" their metadata of the service, rather than current
> > method using the object form.
>
> > - Provides a full example based on TripPin service.
>
> > I encourage you take look at the example service in the test section of
> > this
> > module and see how a sample service can be developed. We are looking for
> > your comments and suggestions to improve upon this framework and your
> > support of the design to carry forward. Please do reply, even that is
> > either
> > a +1 or -1
>
> > I understand that in this new framework, there single interface called
> > "ServiceHandler" for service implementer to develop along with metadata.
> > *If* multiple Processor interfaces is something we really do need, it is
> > fairly straight forward and *easy* to extend the requests to use multiple
> > interfaces as it is currently designed, so that any existing
> > implementations
> > are not broken.
>
> > Please take an hour or two looking through this and provide your feedback,
> > and suggestions to improve upon. I sincerely appreciate your time.
>
> > [1] https://issues.apache.org/jira/browse/OLINGO-482
>
> > [2] https://github.com/apache/olingo-odata4/tree/olingo-server-extension
>
> > Thanks.
>
> > Ramesh..
>
> > http://teiid.org
>
Re: OLINGO-482
Posted by "Bolz, Michael" <mi...@sap.com>.
Hi all,
@Ramesh:
Thanks a lot for your contribution (and push of it into the feature branch).
I created a separate JIRA issue for this extension feature -> [OLINGO-573](https://issues.apache.org/jira/browse/OLINGO-573 <https://issues.apache.org/jira/browse/OLINGO-573>)
As discussed before I can imagine that a more Framework like approach could co-exist as separate module in Olingo (and hence a separate JIRA issue seams to be a good idea).
Additionally we could “tag/flag” all commits with e.g. “[OLINGO-573]” to see which commits belong to this.
Then I hope we get some discussion about this approach and find a good solution how to integrate it into Olingo.
Kind regards,
Michael
> On 11 Feb 2015, at 18:29, Ramesh Reddy <ra...@redhat.com> wrote:
>
> Dear Community,
>
> Based on some discussions on the issue [1], there were several discussions merits of the Processor interface design and how it can be improved for sake of the service developer. Based on those discussions, I have implemented an alternative server side framework as extension. I added this in a separate branch called " olingo-server-extension" , you can also find it at [2]
>
> - This framework currently does not remove any previous Processor interfaces. As extension, these can be evaluated side by side for comparison, then we can decide on the direction best for Olingo in integrating into one module.
> - This framework designed specially to make the job of service developer as easy as possible to develop a OData service in the quickest time.
> - Tries to enforce the odata specification rules, where they need to be, before service implementer receives the request for processing
> - Moves Context URL processing away from service implementer
> - Automatically works with registered serializers based on the "Content-Type" defined on the request
> - Makes the building of response, based on request, such that it reflects the context of the request. Thus eliminates service implementer violating the spec expectations.
> - Provides $metadata schema parser in server side, using which a service implementer can "define" their metadata of the service, rather than current method using the object form.
> - Provides a full example based on TripPin service.
>
> I encourage you take look at the example service in the test section of this module and see how a sample service can be developed. We are looking for your comments and suggestions to improve upon this framework and your support of the design to carry forward. Please do reply, even that is either a +1 or -1
>
> I understand that in this new framework, there single interface called "ServiceHandler" for service implementer to develop along with metadata. *If* multiple Processor interfaces is something we really do need, it is fairly straight forward and *easy* to extend the requests to use multiple interfaces as it is currently designed, so that any existing implementations are not broken.
>
> Please take an hour or two looking through this and provide your feedback, and suggestions to improve upon. I sincerely appreciate your time.
>
> [1] https://issues.apache.org/jira/browse/OLINGO-482
> [2] https://github.com/apache/olingo-odata4/tree/olingo-server-extension
>
> Thanks.
>
> Ramesh..
> http://teiid.org