[
https://issues.apache.org/jira/browse/OLINGO-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328946#comment-14328946
]
Ramesh Reddy commented on OLINGO-573:
-------------------------------------
Thanks [[email protected]]
Yes, something like that is easily possible using this framework, all one needs
to do a implement "ServiceHandler" interface that can process the defined
annotations and delegate the call. In fact, I was going to make comment about
Annotation based approach as in client too. IMO, the major reason extended
framework(s) possible because, most of the specification related stuff
(validation of method, operation type, context-url, serialization, response
handling) handled either before or after the {quote}Processor{quote}'s call,
without it, it is bare method call, and service developer needs to know a lot
more about OData specification before they write single line of code. Once I
have tightened this up, then we can work on Annotation based work.
> Olingo-server-extension with framework like approach for request handling
> -------------------------------------------------------------------------
>
> Key: OLINGO-573
> URL: https://issues.apache.org/jira/browse/OLINGO-573
> Project: Olingo
> Issue Type: New Feature
> Components: odata4-server
> Affects Versions: (Java) V4 4.0.0-beta-02
> Reporter: Michael Bolz
>
> Dear Community,
> Based on some discussions on OLINGO-482, 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
> [GitHub|https://github.com/apache/olingo-odata4/tree/olingo-server-extension]
> - 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.
> Thanks.
> Ramesh..
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
