You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@olingo.apache.org by Anil G <gv...@gmail.com> on 2015/05/19 14:31:36 UTC
Olingo Java v4 Design
Hi,
Started using Olingo Beta 03. The insufficient sample makes it hard for
quick understanding of what to do for so many other operations beyond GET.
But I guess that will get addressed during GA.
But a question that is bothering me is the complex design of Olingo. I have
used odata4j and maintained a code of it myself. It had a great design
though buggy. I have implemented OData v2 & v4 protocols myself in our
internal framework. But I do not understand why the Olingo is designed the
way it is.
I suppose one of the design elements was not to get tied to JAX-RS so it's
pure servlet based. That is great but comes at a cost. But the APIs are
hard to understand, at least for the beginners.
For example the UriInfo and its methods, expectation of having to iterate
through Uri path elements rather than a simple access to the entity set
string or the id parameter string in it in one straight call.
Or say, based on the request headers, it's very clear what kind of a
serializer to use but the user has to to write 4 lines of code to build a
serializer object on his own? There is just too much boilerplate code.
Looks like this complex design is an outcome of offering too much
flexibility to the users. Probably we should have some simple wrappers and
helpers which offer straight & simple APIs for easy adaption?
These comments are based on my initial impressions and are only intended to
make Olingo very simple to use.
Thanks & Regards
Anil
Re: Olingo Java v4 Design
Posted by Anil G <gv...@gmail.com>.
Ramesh, thank you. Will take a look sometime :)
For now, fight with olingo with the help of its source code ;)
On Tue, May 19, 2015 at 7:02 PM, Frédéric SOUCHU <
Frederic.SOUCHU@ingenico.com> wrote:
> Similar feedback from my limited V4 provider.
>
>
>
> Most of the examples or articles on developing a provider have the same
> flaws:
>
> - They either take an in-memory dataset (without any real input
> validation, 'dynamic' nested navigation,…)
>
> - The raw database is exposed using a projection of the Odata
> URL into SQL (security bell ringing!)
>
>
>
> OData 'providers' are certainly in need of a realistic implementation
> pattern.
>
> That is, to translate the URL into a set of steps that can be first mapped
> to a business layer then channeled to the actual storage medium (DB…).
>
> Good to see this new 'ServiceHandler' interface – I'll see how it fits the
> bill!
>
>
>
> Cheers,
>
> Frederic
>
>
>
>
>
> *From:* Ramesh Reddy [mailto:rareddy@redhat.com]
> *Sent:* 19 May 2015 14:57
> *To:* user@olingo.apache.org
> *Subject:* Re: Olingo Java v4 Design
>
>
>
> Anil,
>
>
>
> I suggest you take a look at this example [1] and unit test based on it
> [2] to showcase the interaction. This is parallel framework to the one in
> the "core", and came out of some the same concerns that you have. This one
> only uses single interface [3] and much more concise. This framework also
> takes care of lot of boiler plate code in terms generating the contextURL,
> response serialization, response codes, input parsing, CSDL based metadata
> definition for the service etc. Example is pretty straight forward, I do
> intend to write some documentation soon. Take look at this and let me know
> your feedback. I am willing to make further changes based on the feedback.
>
>
>
> +1 for JAX-RS free design, Olingo does offer pretty solid base framework.
>
>
>
> Ramesh..
>
>
>
> [1]
> https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/test/java/org/apache/olingo/server/example/TripPinServlet.java
>
> [2]
> https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/test/java/org/apache/olingo/server/example/TripPinServiceTest.java,
>
>
> [3]
> https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/main/java/org/apache/olingo/server/core/ServiceHandler.java
>
>
>
>
>
>
> ------------------------------
>
> Hi,
>
>
>
> Started using Olingo Beta 03. The insufficient sample makes it hard for
> quick understanding of what to do for so many other operations beyond GET.
> But I guess that will get addressed during GA.
>
>
>
> But a question that is bothering me is the complex design of Olingo. I
> have used odata4j and maintained a code of it myself. It had a great design
> though buggy. I have implemented OData v2 & v4 protocols myself in our
> internal framework. But I do not understand why the Olingo is designed the
> way it is.
>
>
>
> I suppose one of the design elements was not to get tied to JAX-RS so it's
> pure servlet based. That is great but comes at a cost. But the APIs are
> hard to understand, at least for the beginners.
>
>
>
> For example the UriInfo and its methods, expectation of having to iterate
> through Uri path elements rather than a simple access to the entity set
> string or the id parameter string in it in one straight call.
>
> Or say, based on the request headers, it's very clear what kind of a
> serializer to use but the user has to to write 4 lines of code to build a
> serializer object on his own? There is just too much boilerplate code.
>
>
>
> Looks like this complex design is an outcome of offering too much
> flexibility to the users. Probably we should have some simple wrappers and
> helpers which offer straight & simple APIs for easy adaption?
>
>
>
> These comments are based on my initial impressions and are only intended
> to make Olingo very simple to use.
>
>
>
> Thanks & Regards
>
> Anil
>
>
>
>
>
>
>
RE: Olingo Java v4 Design
Posted by Frédéric SOUCHU <Fr...@ingenico.com>.
Ramesh,
The version going to production is using the ServiceHandler base class (using the Beta 03).
It definitely reduced the learning curve to get a working provider (lot less low level code).
Now that we have a pattern to process the request, select fields and translate that to a DB request, some other services might make the jump to OData.
I am a bit disappointed, the latest 'how to' articles are not using ServiceHandler!
Regards,
Frederic
From: Ramesh Reddy [mailto:rareddy@redhat.com]
Sent: 19 August 2015 22:56
To: user@olingo.apache.org
Subject: Re: Olingo Java v4 Design
Frederic, Anil,
Any feedback on ServiceHandler interface? V4 final seems to be coming close, any feedback to make it better would be very helpful.
Ramesh..
________________________________
Similar feedback from my limited V4 provider.
Most of the examples or articles on developing a provider have the same flaws:
- They either take an in-memory dataset (without any real input validation, 'dynamic' nested navigation,…)
- The raw database is exposed using a projection of the Odata URL into SQL (security bell ringing!)
OData 'providers' are certainly in need of a realistic implementation pattern.
That is, to translate the URL into a set of steps that can be first mapped to a business layer then channeled to the actual storage medium (DB…).
Good to see this new 'ServiceHandler' interface – I'll see how it fits the bill!
Cheers,
Frederic
From: Ramesh Reddy [mailto:rareddy@redhat.com]
Sent: 19 May 2015 14:57
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: Olingo Java v4 Design
Anil,
I suggest you take a look at this example [1] and unit test based on it [2] to showcase the interaction. This is parallel framework to the one in the "core", and came out of some the same concerns that you have. This one only uses single interface [3] and much more concise. This framework also takes care of lot of boiler plate code in terms generating the contextURL, response serialization, response codes, input parsing, CSDL based metadata definition for the service etc. Example is pretty straight forward, I do intend to write some documentation soon. Take look at this and let me know your feedback. I am willing to make further changes based on the feedback.
+1 for JAX-RS free design, Olingo does offer pretty solid base framework.
Ramesh..
[1] https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/test/java/org/apache/olingo/server/example/TripPinServlet.java
[2] https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/test/java/org/apache/olingo/server/example/TripPinServiceTest.java,
[3] https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/main/java/org/apache/olingo/server/core/ServiceHandler.java
________________________________
Hi,
Started using Olingo Beta 03. The insufficient sample makes it hard for quick understanding of what to do for so many other operations beyond GET. But I guess that will get addressed during GA.
But a question that is bothering me is the complex design of Olingo. I have used odata4j and maintained a code of it myself. It had a great design though buggy. I have implemented OData v2 & v4 protocols myself in our internal framework. But I do not understand why the Olingo is designed the way it is.
I suppose one of the design elements was not to get tied to JAX-RS so it's pure servlet based. That is great but comes at a cost. But the APIs are hard to understand, at least for the beginners.
For example the UriInfo and its methods, expectation of having to iterate through Uri path elements rather than a simple access to the entity set string or the id parameter string in it in one straight call.
Or say, based on the request headers, it's very clear what kind of a serializer to use but the user has to to write 4 lines of code to build a serializer object on his own? There is just too much boilerplate code.
Looks like this complex design is an outcome of offering too much flexibility to the users. Probably we should have some simple wrappers and helpers which offer straight & simple APIs for easy adaption?
These comments are based on my initial impressions and are only intended to make Olingo very simple to use.
Thanks & Regards
Anil
Re: Olingo Java v4 Design
Posted by Ramesh Reddy <ra...@redhat.com>.
Frederic, Anil,
Any feedback on ServiceHandler interface? V4 final seems to be coming close, any feedback to make it better would be very helpful.
Ramesh..
----- Original Message -----
> Similar feedback from my limited V4 provider.
> Most of the examples or articles on developing a provider have the same
> flaws:
> - They either take an in-memory dataset (without any real input validation,
> 'dynamic' nested navigation,…)
> - The raw database is exposed using a projection of the Odata URL into SQL
> (security bell ringing!)
> OData 'providers' are certainly in need of a realistic implementation
> pattern.
> That is, to translate the URL into a set of steps that can be first mapped to
> a business layer then channeled to the actual storage medium (DB…).
> Good to see this new 'ServiceHandler' interface – I'll see how it fits the
> bill!
> Cheers,
> Frederic
> From: Ramesh Reddy [mailto:rareddy@redhat.com]
> Sent: 19 May 2015 14:57
> To: user@olingo.apache.org
> Subject: Re: Olingo Java v4 Design
> Anil,
> I suggest you take a look at this example [1] and unit test based on it [2]
> to showcase the interaction. This is parallel framework to the one in the
> "core", and came out of some the same concerns that you have. This one only
> uses single interface [3] and much more concise. This framework also takes
> care of lot of boiler plate code in terms generating the contextURL,
> response serialization, response codes, input parsing, CSDL based metadata
> definition for the service etc. Example is pretty straight forward, I do
> intend to write some documentation soon. Take look at this and let me know
> your feedback. I am willing to make further changes based on the feedback.
> +1 for JAX-RS free design, Olingo does offer pretty solid base framework.
> Ramesh..
> [1]
> https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/test/java/org/apache/olingo/server/example/TripPinServlet.java
> [2]
> https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/test/java/org/apache/olingo/server/example/TripPinServiceTest.java,
> [3]
> https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/main/java/org/apache/olingo/server/core/ServiceHandler.java
> ----- Original Message -----
> > Hi,
>
> > Started using Olingo Beta 03. The insufficient sample makes it hard for
> > quick
> > understanding of what to do for so many other operations beyond GET. But I
> > guess that will get addressed during GA.
>
> > But a question that is bothering me is the complex design of Olingo. I have
> > used odata4j and maintained a code of it myself. It had a great design
> > though buggy. I have implemented OData v2 & v4 protocols myself in our
> > internal framework. But I do not understand why the Olingo is designed the
> > way it is.
>
> > I suppose one of the design elements was not to get tied to JAX-RS so it's
> > pure servlet based. That is great but comes at a cost. But the APIs are
> > hard
> > to understand, at least for the beginners.
>
> > For example the UriInfo and its methods, expectation of having to iterate
> > through Uri path elements rather than a simple access to the entity set
> > string or the id parameter string in it in one straight call.
>
> > Or say, based on the request headers, it's very clear what kind of a
> > serializer to use but the user has to to write 4 lines of code to build a
> > serializer object on his own? There is just too much boilerplate code.
>
> > Looks like this complex design is an outcome of offering too much
> > flexibility
> > to the users. Probably we should have some simple wrappers and helpers
> > which
> > offer straight & simple APIs for easy adaption?
>
> > These comments are based on my initial impressions and are only intended to
> > make Olingo very simple to use.
>
> > Thanks & Regards
>
> > Anil
>
RE: Olingo Java v4 Design
Posted by Frédéric SOUCHU <Fr...@ingenico.com>.
Similar feedback from my limited V4 provider.
Most of the examples or articles on developing a provider have the same flaws:
- They either take an in-memory dataset (without any real input validation, 'dynamic' nested navigation,…)
- The raw database is exposed using a projection of the Odata URL into SQL (security bell ringing!)
OData 'providers' are certainly in need of a realistic implementation pattern.
That is, to translate the URL into a set of steps that can be first mapped to a business layer then channeled to the actual storage medium (DB…).
Good to see this new 'ServiceHandler' interface – I'll see how it fits the bill!
Cheers,
Frederic
From: Ramesh Reddy [mailto:rareddy@redhat.com]
Sent: 19 May 2015 14:57
To: user@olingo.apache.org
Subject: Re: Olingo Java v4 Design
Anil,
I suggest you take a look at this example [1] and unit test based on it [2] to showcase the interaction. This is parallel framework to the one in the "core", and came out of some the same concerns that you have. This one only uses single interface [3] and much more concise. This framework also takes care of lot of boiler plate code in terms generating the contextURL, response serialization, response codes, input parsing, CSDL based metadata definition for the service etc. Example is pretty straight forward, I do intend to write some documentation soon. Take look at this and let me know your feedback. I am willing to make further changes based on the feedback.
+1 for JAX-RS free design, Olingo does offer pretty solid base framework.
Ramesh..
[1] https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/test/java/org/apache/olingo/server/example/TripPinServlet.java
[2] https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/test/java/org/apache/olingo/server/example/TripPinServiceTest.java,
[3] https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/main/java/org/apache/olingo/server/core/ServiceHandler.java
________________________________
Hi,
Started using Olingo Beta 03. The insufficient sample makes it hard for quick understanding of what to do for so many other operations beyond GET. But I guess that will get addressed during GA.
But a question that is bothering me is the complex design of Olingo. I have used odata4j and maintained a code of it myself. It had a great design though buggy. I have implemented OData v2 & v4 protocols myself in our internal framework. But I do not understand why the Olingo is designed the way it is.
I suppose one of the design elements was not to get tied to JAX-RS so it's pure servlet based. That is great but comes at a cost. But the APIs are hard to understand, at least for the beginners.
For example the UriInfo and its methods, expectation of having to iterate through Uri path elements rather than a simple access to the entity set string or the id parameter string in it in one straight call.
Or say, based on the request headers, it's very clear what kind of a serializer to use but the user has to to write 4 lines of code to build a serializer object on his own? There is just too much boilerplate code.
Looks like this complex design is an outcome of offering too much flexibility to the users. Probably we should have some simple wrappers and helpers which offer straight & simple APIs for easy adaption?
These comments are based on my initial impressions and are only intended to make Olingo very simple to use.
Thanks & Regards
Anil
Re: Olingo Java v4 Design
Posted by Ramesh Reddy <ra...@redhat.com>.
Anil,
I suggest you take a look at this example [1] and unit test based on it [2] to showcase the interaction. T his is parallel framework to the one in the "core", and came out of some the same concerns that you have. This one only uses single interface [3] and much more concise. This framework also takes care of lot of boiler plate code in terms generating the contextURL, response serialization, response codes, input parsing, CSDL based metadata definition for the service etc. Example is pretty straight forward, I do intend to write some documentation soon. Take look at this and let me know your feedback. I am willing to make further changes based on the feedback.
+1 for JAX-RS free design, Olingo does offer pretty solid base framework.
Ramesh..
[1] https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/test/java/org/apache/olingo/server/example/TripPinServlet.java
[2] https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/test/java/org/apache/olingo/server/example/TripPinServiceTest.java,
[3] https://github.com/apache/olingo-odata4/blob/master/lib/server-core-ext/src/main/java/org/apache/olingo/server/core/ServiceHandler.java
----- Original Message -----
> Hi,
> Started using Olingo Beta 03. The insufficient sample makes it hard for quick
> understanding of what to do for so many other operations beyond GET. But I
> guess that will get addressed during GA.
> But a question that is bothering me is the complex design of Olingo. I have
> used odata4j and maintained a code of it myself. It had a great design
> though buggy. I have implemented OData v2 & v4 protocols myself in our
> internal framework. But I do not understand why the Olingo is designed the
> way it is.
> I suppose one of the design elements was not to get tied to JAX-RS so it's
> pure servlet based. That is great but comes at a cost. But the APIs are hard
> to understand, at least for the beginners.
> For example the UriInfo and its methods, expectation of having to iterate
> through Uri path elements rather than a simple access to the entity set
> string or the id parameter string in it in one straight call.
> Or say, based on the request headers, it's very clear what kind of a
> serializer to use but the user has to to write 4 lines of code to build a
> serializer object on his own? There is just too much boilerplate code.
> Looks like this complex design is an outcome of offering too much flexibility
> to the users. Probably we should have some simple wrappers and helpers which
> offer straight & simple APIs for easy adaption?
> These comments are based on my initial impressions and are only intended to
> make Olingo very simple to use.
> Thanks & Regards
> Anil