Hi Stephan
On 02/12/13 16:02, Klevenz, Stephan wrote:
Hi Sergey,
This is a cool proposal and I think both projects, CXF and Olingo, can
profit from such an activity.
I hope so too
I had a look into [1] and [2] and see a proximity to OData which has a URI
based query syntax which us parsed by Olingo and ends up into a abstract
syntax tree to be traversed by the visitor pattern as well. To get a
better understanding about what should be achieved can you please give a
use case just for example?
What I'm looking for is for CXF users which have already started using
its Search API be able to reuse the same custom or shipped CXF visitors
when OData query expressions are used.
Right now most of CXF Search API code is not aware of the fact FIQL
queries are used, the only piece of code which does is
org.apache.cxf.jaxrs.ext.search.SearchConditionParser FIQL-aware
implementation.
So IMHO if we can come up with OData-aware
org.apache.cxf.jaxrs.ext.search.SearchConditionParser implementation
which would use Olingo parser and adapt the OData query to the
constraints of CXF Search API, which indeed appears to be possible, then
it would let CXF users reuses the same code with FIQL or OData queries
which will be positive.
It may also simplify for us integrating with Olingo at the higher-level
(in the tooling, etc).
As I said I don't expect the full OData support done within CXF Search
API constraints, the CXF users keen exploring OData to the full will
move to working with Olingo directly, what I'd be happy to get supported
at the CXF level with the help of Olingo is this part:
http://www.odata.org/documentation/odata-v3-documentation/url-conventions/#5_Query_Options
(Specifically examples in 5.1.2.1) and the extra filter options as
suggested by Francesco.
I'm not sure CXF can also support paths like "/products(1)/customers"
but may we can get an Olingo Parser wrapper adapting such paths with
some conventions...
To start the effort in a CXF context is fine and it can later be decided
to have a substantial contribution into Olingo. That is a standard
procedure for Apache projects, right?
Yes sure; for now we can do the actual parser in CXF and ask at Olingo
all the questions
If you have detailed questions to Olingo then do not hesitate to query our
mailing list.
Sure, thanks
Sergey
Greetings,
Stephan
[1] http://tools.ietf.org/html/draft-nottingham-atompub-fiql-00
[2] http://cxf.apache.org/docs/jax-rs-search.html
On 02.12.13 12:21, "Sergey Beryozkin" <[email protected]> wrote:
Hi,
On 29/11/13 17:40, Sergey Beryozkin wrote:
Hi Olingo Team,
I'm interested in getting OData directly supported in Apache CXF, please
see [1].
CXF offers its own Search API which currently supports Feed Item Query
Language (FIQL). It works similar to the way Olingo works, a FIQL parser
parsers a FIQL expression and users register so called search visitors
which adapt the parsed expression to other query languages such as SQL,
etc.
IMHO supporting OData directly with CXF Search API with the help of
Olingo will be really nice. It will help CXF users to get a better
understanding of OData and perhaps will encourage them to work more with
Olingo in cases where a CXF Olingo-based solution will prove limiting as
suggested at [1].
After thinking about this for a while, it appears to me that perhaps we
should simply start the work in CXF and start asking questions on Olingo
users or dev lists and may be offer some patches if needed and if the
analysis will prove implementing [1] is realistic.
I'd like to ask however: do you reckon it might make sense to do it in
Olingo itself ? For example, we'd create a new Maven tree, example,
/integration/cxf and work there. Perhaps that can be distracting for the
core Olingo effort, so for now I'm inclined to do it at CXF level,
Note, if the team decides that the Olingo project can actually 'host'
the CXF or other Olingo-based 3rd party extensions then as far as we are
concerned we can move a CXF wrapper to Olingo immediately.
What I'd like to say is that we can start experimenting with Olingo
first, ask questions, do patches if needed, and once we have a CXF
Olingo wrapper working we can update this thread and solicit some
feedback on where we'd be better off hosting it.
Hope it sounds reasonable:-)
Thanks, Sergey
Comments are welcome
Thanks, Sergey
[1] https://issues.apache.org/jira/browse/CXF-5430
