March 2019 - teiid-issues - Jboss List Archives

[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: --------------------------------------- So I am not sure if I understood you correctly. Question 1 regarding Olingo is clear, seems I looked at the wrong release :) Question 2: Can I copy olingo v4 build from current olingo source tree on top of teiid 12.x? My understanding of your answer is yes. Is my interpretation correct? > 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.2 > > > 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)

7 years, 1 month

1
0
0 / 0

[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: ------------------------------------- Unfortunately no, enquiring now. > 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.2 > > > 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)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-5649) Isolate wildfly/cli dependent documentation

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5649?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5649. ----------------------------------- Resolution: Done Marking the initial work as resolved. The reference guide is now buildable without eap/wildfly references as shown in the spring folder - https://github.com/teiid/teiid-documents/tree/master/spring The travis job for now will only build the wildfly / all doc set. As indicated in the last comment we could look toward moving the spring folder to teiid-spring-boot to better manage with it's versions and specific content. For now I'll continue on the path of refining the shared docs - templatizing the product name, ddl examples, refining the client guide, etc. > Isolate wildfly/cli dependent documentation > ------------------------------------------- > > Key: TEIID-5649 > URL: https://issues.jboss.org/browse/TEIID-5649 > Project: Teiid > Issue Type: Quality Risk > Components: Documentation > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.1 > > > To better support or various environments we need to isolate docs in the main set that are dependent upon wildfly/cli. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-5592) Update or deprecate teiid-quickstarts

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5592?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5592: ---------------------------------- Fix Version/s: 12.2 (was: 12.1) > Update or deprecate teiid-quickstarts > ------------------------------------- > > Key: TEIID-5592 > URL: https://issues.jboss.org/browse/TEIID-5592 > Project: Teiid > Issue Type: Quality Risk > Components: Quick Starts > Reporter: Steven Hawkins > Assignee: Van Halbert > Priority: Major > Fix For: 12.2 > > > The last update to the quickstarts was for Teiid 10 - which should have been largely compatible with Teiid 11. However this should be reviewed and updated for Teiid 11 - or we should deprecate them and update teiid.io appropriately. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-5649) Isolate wildfly/cli dependent documentation

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5649?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5649: --------------------------------------- > Should we move documents from spring boot here then? I have been wanting to keep docs/examples with the code itself such that we can keep them fresh. Or if there is a way to cross-link from spring boot repo here? More than likely we'll link (using a submodule) to the common doc repo from spring boot so that the "spring" folder assets can be managed there. > Isolate wildfly/cli dependent documentation > ------------------------------------------- > > Key: TEIID-5649 > URL: https://issues.jboss.org/browse/TEIID-5649 > Project: Teiid > Issue Type: Quality Risk > Components: Documentation > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.1 > > > To better support or various environments we need to isolate docs in the main set that are dependent upon wildfly/cli. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-46) Support override translators

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-46?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIIDSB-46: ------------------------------------- Here atleast the scope issue is resolved, vdb scope == global scope. The issue is we can treat them like extended translators with code, but it will not satisfy the grammar, which is the issue with converted vdbs :( > Support override translators > ---------------------------- > > Key: TEIIDSB-46 > URL: https://issues.jboss.org/browse/TEIIDSB-46 > Project: Teiid Spring Boot > Issue Type: Enhancement > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.0.3 > > > Override translators will need supported especially for migration scenarios. By default the current logic will map ddl overrides to the corresponding vdb xml equivalents, which will then trigger a failure to deploy. So things will need to be overriden to map the override to actually installing the translator (there is already an EmbeddedServer method for that given a translator type and properties). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-5649) Isolate wildfly/cli dependent documentation

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIID-5649?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-5649: ------------------------------------- Sounds good. I can not visualize the whole thing yet. Should we move documents from spring boot here then? I have been wanting to keep docs/examples with the code itself such that we can keep them fresh. Or if there is a way to cross-link from spring boot repo here? > Isolate wildfly/cli dependent documentation > ------------------------------------------- > > Key: TEIID-5649 > URL: https://issues.jboss.org/browse/TEIID-5649 > Project: Teiid > Issue Type: Quality Risk > Components: Documentation > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.1 > > > To better support or various environments we need to isolate docs in the main set that are dependent upon wildfly/cli. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-46) Support override translators

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-46?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIIDSB-46: --------------------------------------- It's supported in the grammar, and it will work in WildFly - but we've had that long standing difference with embedded where we made translators globally scoped. So by default we made embedded reject vdb scoped translators. > Support override translators > ---------------------------- > > Key: TEIIDSB-46 > URL: https://issues.jboss.org/browse/TEIIDSB-46 > Project: Teiid Spring Boot > Issue Type: Enhancement > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.0.3 > > > Override translators will need supported especially for migration scenarios. By default the current logic will map ddl overrides to the corresponding vdb xml equivalents, which will then trigger a failure to deploy. So things will need to be overriden to map the override to actually installing the translator (there is already an EmbeddedServer method for that given a translator type and properties). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-46) Support override translators

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIIDSB-46?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIIDSB-46: ------------------------------------- I was some reason thinking this will be supported by the engine itself, but will not. I will have a patch ready shortly. > Support override translators > ---------------------------- > > Key: TEIIDSB-46 > URL: https://issues.jboss.org/browse/TEIIDSB-46 > Project: Teiid Spring Boot > Issue Type: Enhancement > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.0.3 > > > Override translators will need supported especially for migration scenarios. By default the current logic will map ddl overrides to the corresponding vdb xml equivalents, which will then trigger a failure to deploy. So things will need to be overriden to map the override to actually installing the translator (there is already an EmbeddedServer method for that given a translator type and properties). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-5545) Odata V4 Batch processing does not work as teiid/olingo rejects "Accept: multipart/mixed" request header

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5545: --------------------------------------- > I would like to come back on you regarding the Olingo topic. I have seen that Olingo 2.0.11 was released in February, and I hope that the next Teiid release 12.0.2 will include it. Is this planned? There are two versions of olingo that we use. We only use Olingo 2 for connection to OData 2 sources. We use Olingo 4 for generating OData 4 services and connecting to OData 4 sources. Unfortunately we are still waiting on the next OData 4 release. > I was therefore wondering, if there have been changes in the teiid-olingo-patches-X.jar file between version 11.2.0 and 12.1 that would make it infeasible to just copy the olingo library files over to the files included in teiid 12.1. For 12.x a simplification was made to remove our olingo patches jar. [~rareddy] Can they give any guidance on a 4.5.1 or 4.6 release date? > 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.2 > > > 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)

7 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues March 2019