[JBoss JIRA] (TEIID-5545) Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
by Christoph John (Jira)
[ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin... ]
Christoph John edited comment on TEIID-5545 at 1/2/19 2:07 PM:
---------------------------------------------------------------
Hello Ramesh,
thanks. Ok, first part was simple. I cloned Olingo from git and could build it without errors. The dependency list from this build I could get with (mvn dependency:tree). Seems I cannot attach files here.
I would like to change the Olingo library now on a Teiid 9.0 and on a Teiid 11.2 instance. So far I just had a look into Teiid 9.0.
Question 1: I assume only the modules under the following path need to be exchanged. Is this correct?
/opt/jboss/wildfly/modules/system/layers/dv/org/apache/olingo
This is to say under ./apache/olingo I have to replace the jars in the folders client, commons and server. Is this the full list of relevant jars I have to exchange?
./client/main/odata-client-api-4.2.0-teiid-5.jar
./client/main/odata-client-core-4.2.0-teiid-5.jar
./commons/main/odata-commons-api-4.2.0-teiid-5.jar
./commons/main/odata-commons-core-4.2.0-teiid-5.jar
./server/main/odata-server-api-4.2.0-teiid-5.jar
./server/main/odata-server-core-4.2.0-teiid-5.jar
./server/main/odata-server-core-ext-4.2.0-teiid-5.jar
./server/main/teiid-olingo-patches-9.0.6.jar
------------------------------------------------------------------------
Question 2: The file teiid-olingo-patches-9.0.6.jar seem to be not part of Olingo. Would I have to rebuild this as well? In case of yes, how would I have to do it and from where could I get the sources
------------------------------------------------------------------------
Question 3: How can I extract the dependencies of the jar files that are part of Teiid-Wildfly?
Thanks for your help.
was (Author: cjohn001):
Hello Ramesh,
thanks. Ok, first part was simple. I cloned Olingo from git and could build it without errors. The dependency list from this build (mvn dependency:tree) is in the attached file.
I would like to change the Olingo library now on a Teiid 9.0 and on a Teiid 11.2 instance. So far I just had a look into Teiid 9.0.
Question 1: I assume only the modules under the following path need to be exchanged. Is this correct?
/opt/jboss/wildfly/modules/system/layers/dv/org/apache/olingo
This is to say under ./apache/olingo I have to replace the jars in the folders client, commons and server. Is this the full list of relevant jars I have to exchange?
./client/main/odata-client-api-4.2.0-teiid-5.jar
./client/main/odata-client-core-4.2.0-teiid-5.jar
./commons/main/odata-commons-api-4.2.0-teiid-5.jar
./commons/main/odata-commons-core-4.2.0-teiid-5.jar
./server/main/odata-server-api-4.2.0-teiid-5.jar
./server/main/odata-server-core-4.2.0-teiid-5.jar
./server/main/odata-server-core-ext-4.2.0-teiid-5.jar
./server/main/teiid-olingo-patches-9.0.6.jar
------------------------------------------------------------------------
Question 2: The file teiid-olingo-patches-9.0.6.jar seem to be not part of Olingo. Would I have to rebuild this as well? In case of yes, how would I have to do it and from where could I get the sources
------------------------------------------------------------------------
Question 3: How can I extract the dependencies of the jar files that are part of Teiid-Wildfly?
Thanks for your help.
> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
> Key: TEIID-5545
> URL: https://issues.jboss.org/browse/TEIID-5545
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 11.2
> Reporter: Christoph John
> Assignee: Ramesh Reddy
> Priority: Critical
> Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
> Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However,
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5545) Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
by Christoph John (Jira)
[ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin... ]
Christoph John commented on TEIID-5545:
---------------------------------------
Hello Ramesh,
thanks. Ok, first part was simple. I cloned Olingo from git and could build it without errors. The dependency list from this build (mvn dependency:tree) is in the attached file.
I would like to change the Olingo library now on a Teiid 9.0 and on a Teiid 11.2 instance. So far I just had a look into Teiid 9.0.
Question 1: I assume only the modules under the following path need to be exchanged. Is this correct?
/opt/jboss/wildfly/modules/system/layers/dv/org/apache/olingo
This is to say under ./apache/olingo I have to replace the jars in the folders client, commons and server. Is this the full list of relevant jars I have to exchange?
./client/main/odata-client-api-4.2.0-teiid-5.jar
./client/main/odata-client-core-4.2.0-teiid-5.jar
./commons/main/odata-commons-api-4.2.0-teiid-5.jar
./commons/main/odata-commons-core-4.2.0-teiid-5.jar
./server/main/odata-server-api-4.2.0-teiid-5.jar
./server/main/odata-server-core-4.2.0-teiid-5.jar
./server/main/odata-server-core-ext-4.2.0-teiid-5.jar
./server/main/teiid-olingo-patches-9.0.6.jar
------------------------------------------------------------------------
Question 2: The file teiid-olingo-patches-9.0.6.jar seem to be not part of Olingo. Would I have to rebuild this as well? In case of yes, how would I have to do it and from where could I get the sources
------------------------------------------------------------------------
Question 3: How can I extract the dependencies of the jar files that are part of Teiid-Wildfly?
Thanks for your help.
> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
> Key: TEIID-5545
> URL: https://issues.jboss.org/browse/TEIID-5545
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 11.2
> Reporter: Christoph John
> Assignee: Ramesh Reddy
> Priority: Critical
> Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
> Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However,
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5495) Add support for graphql sources
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIID-5495?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5495:
-------------------------------------
agree. I think we can do two levels of support.
1) Basic, supply json and get json back. Current WS translator should suffice that. Need to show some examples.
2) Going custom translator route, we will get a JSON document that has One-2-Many based relationships (mostly). Where this becomes challenging is as you mention input parameter mapping. As these parameters could be just criteria on field or implicit paging techniques or something completely random. The last one is troublesome, but if we take an approach as in the procedure to relational where parameters are added to response (entity) then these can be treated similarly to the criteria.
> Add support for graphql sources
> -------------------------------
>
> Key: TEIID-5495
> URL: https://issues.jboss.org/browse/TEIID-5495
> Project: Teiid
> Issue Type: Feature Request
> Components: Connector API
> Reporter: Steven Hawkins
> Assignee: Van Halbert
> Priority: Major
> Fix For: 12.x
>
>
> We should create translator support for graphql, which will also help us evaluate supporting graphql as a front end as well.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5581) No @nextlink for virtualized procedure
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIID-5581?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5581:
-------------------------------------
[~shawkins] We can pursue the upstream fix, the exception should be a stop-gap measure until we can provide a solution IMO. I believe if we want we can even provide an extended serializer in Teiid code meanwhile.
> No @nextlink for virtualized procedure
> --------------------------------------
>
> Key: TEIID-5581
> URL: https://issues.jboss.org/browse/TEIID-5581
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.12.16.6_4
> Reporter: Colin Mondesir
> Assignee: Steven Hawkins
> Priority: Major
> Attachments: example.xmi, procExample_Odata_Results.xml, procExample_SELECT.sql
>
>
> If we query a table "Field" via VDB, we get the following line in XML :
> <a:link rel="next" href="http://<IP-address>:8080/odata4/UDVvdb.13/BusinessObjects/Field?$skiptoken=6lS4u9tYdm4j,256"/>
> This allow end-user to loop on results easily.
> But when we call virtualized procedure, we do not see that line.
> It looks like :
> <m:value xmlns:m="http://docs.oasis-open.org/odata/ns/metadata" xmlns:d="http://docs.oasis-open.org/odata/ns/data" xmlns:a="http://www.w3.org/2005/Atom" m:type="#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)" m:context="$metadata#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)">
> [List of <m:element>]
> </m:value>
> Odata batch is currently limited to 256 so without a next link it's not possible to get to the rest of the data.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5563:
-------------------------------------
Couple suggestions.
1) It seems appropriate to introduce the "org.teiid.wildfly" as groupid for any projects underneath "wildfly" module.
2) Consider getting rid of the duplicate definition of "groupid" in the projects like "connector-xxxx", that will base their group id to "org.teiid.wildfly.resource-adapters". If we can't do (1) then at least introduce that for resource-adapters module and down.
3) Consider renaming project from "connector-xxxx" to "xxxx-ra" or "ra-xxxx", this along with group-id clearly separate them as WildFly constructs. But this is not really required.
4) org.teiid.translator makes sense, but only for aesthetic reasons. Probably provides more clarity for nomenclature and removes "connectors" altogether which could be duplicate in times with connector, and relieves us from legacy names.
(1) one involves many pom changes, 4 will result in a lot of doc changes I think.
> Separate the Teiid WildFly distribution into their own repo or module
> ---------------------------------------------------------------------
>
> Key: TEIID-5563
> URL: https://issues.jboss.org/browse/TEIID-5563
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits, Integration Tests
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
>
> With the different types of distributions now being built based on Teiid like
> * WildFly
> * Thorntail
> * SpringBoot
> * Embedded
> Having main `github.com/teiid` repo contain artifacts for WildFly distribution poses an unnecessary dependency burden on other distributions. For example, the resource adapters are mainly for use with WildFly and Thorntail V2. They can still be applicable to embedded and SpringBoot as either non-managed connection factories, or require the user to provide appropriate management / pooling. When they are pulled into environments like SpringBoot they will bring several wildfly dependencies / and JEE constructs that are unnecessary - specifically the dependencies jboss-jaxws-api (teiid-api), javax.activation (teiid-core), jboss-transaction-api (teiid-api), and jboss-connector-api (teiid-api).
> This proposal is to separate "teiid" core modules along with all translators into one repository and move all the resource adapters along with any feature-packs and module building into a sperate repository like "teiid-wildfly". With the goal of providing similar connectivity in SpringBoot using as much common logic from SpringBoot (Spring Data in particular) and even Fuse as possible.
> Basically, when finished, the core Teiid modules only provide Maven artifacts along with their clean pom.xml with for direct and maybe transitive dependencies. None of the WildFly based modules support will be here. At worst this may introduce duplicate dependencies into the WildFly environment as we will need to manage all core / translator dependencies independently from those provided by WildFly. Where possible the teiid-api / core modules will need to use the generic javax dependency - or even remove the dependency if possible.
> The "teiid-wildfly" module on the other hand, will exactly preserve what is in the current repo as far feature packs and module building and overall WildFly distribution building.
> A follow-on task we can task we can look into is, converting the main teiid then to use basepom rather than the jboss-parent pom. However, the recommendation is this should be done after, not simultaneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5581) No @nextlink for virtualized procedure
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5581?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5581:
---------------------------------------
[~rareddy] It looks like this will need support in olingo - the serializers for complex type collections have no logic for the next link. Should we pursue an upstream fix, or just throw an exception that indicates the workaround of a procedural relational view instead?
> No @nextlink for virtualized procedure
> --------------------------------------
>
> Key: TEIID-5581
> URL: https://issues.jboss.org/browse/TEIID-5581
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.12.16.6_4
> Reporter: Colin Mondesir
> Assignee: Steven Hawkins
> Priority: Major
> Attachments: example.xmi, procExample_Odata_Results.xml, procExample_SELECT.sql
>
>
> If we query a table "Field" via VDB, we get the following line in XML :
> <a:link rel="next" href="http://<IP-address>:8080/odata4/UDVvdb.13/BusinessObjects/Field?$skiptoken=6lS4u9tYdm4j,256"/>
> This allow end-user to loop on results easily.
> But when we call virtualized procedure, we do not see that line.
> It looks like :
> <m:value xmlns:m="http://docs.oasis-open.org/odata/ns/metadata" xmlns:d="http://docs.oasis-open.org/odata/ns/data" xmlns:a="http://www.w3.org/2005/Atom" m:type="#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)" m:context="$metadata#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)">
> [List of <m:element>]
> </m:value>
> Odata batch is currently limited to 256 so without a next link it's not possible to get to the rest of the data.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5495) Add support for graphql sources
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5495?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5495:
---------------------------------------
[~rareddy] [~rhn-engineering-vhalbert] the expectation here could be as little as something akin to our wsdl support. Construct a json message, get json back for post-processing. Ideally though there should be Java clients available that can provide abstract reading of graphql schema and querying. We could then at least provide a top level entity mapping - an entity would be something that has only optional, non-default arguments. Something with non-optional or default arguments should be represented as a procedure - or perhaps as a table with access pattern(s). However at first glance most graphql java frameworks look to expect Java bindings (which could be generated).
> Add support for graphql sources
> -------------------------------
>
> Key: TEIID-5495
> URL: https://issues.jboss.org/browse/TEIID-5495
> Project: Teiid
> Issue Type: Feature Request
> Components: Connector API
> Reporter: Steven Hawkins
> Assignee: Van Halbert
> Priority: Major
> Fix For: 12.x
>
>
> We should create translator support for graphql, which will also help us evaluate supporting graphql as a front end as well.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5545) Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5545:
-------------------------------------
Happy New Year to you too Christoph.
Basically you want to build Olingo project locally using maven build tool
{code}
/oilingo/mvn clean install
{code}
It will produce the jar files in the `target` directories. You would need to replace the new JAR files with old ones in the WildFly distribution and making sure that the names match. The one caveat is if at all Olingo changed any dependency modules or API then more code on Teiid needs to be modified, this only can be determined after comparing both versions.
> Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header
> --------------------------------------------------------------------------------------------------------
>
> Key: TEIID-5545
> URL: https://issues.jboss.org/browse/TEIID-5545
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 11.2
> Reporter: Christoph John
> Assignee: Ramesh Reddy
> Priority: Critical
> Fix For: 12.1
>
>
> When using Teiid together with SAPUI5/OpenUI5 Odata V4 model, batch processing does not work as Teiid rejects the "Accept: multipart/mixed" header. The issue has been described in
> https://developer.jboss.org/message/986421#986421
> It has been stated that Olingo in general does support multipart messages and it was recommended to remove the header from the request.
> https://developer.jboss.org/message/986425#986425
> Unfortunately this seems to be not easily possible when using the SAPUI5 framework. I addressed the issue in the SAPUI5 forum under the following issue:
> https://github.com/SAP/openui5/issues/2288
> The result of this discussion was, that the header is valid for the send content. As I am no expert in the topic I do not really have an opinion on that. However,
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
> suggests that the header is required. So I am not sure if it is correct or an error to reject the message. However, if Olingo can process the content, it would be great to have a fix for the accept header, or alternatively a config option to enable handling of the Accept header in a way that Olingo processes these data.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months