[JBoss JIRA] (TEIID-5577) Create clean dependencies / separate boms
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5577?page=com.atlassian.jira.plugin... ]
Van Halbert closed TEIID-5577.
------------------------------
Resolution: Duplicate Issue
This change was incorporated with the TEIID-5563 changes.
> Create clean dependencies / separate boms
> -----------------------------------------
>
> Key: TEIID-5577
> URL: https://issues.jboss.org/browse/TEIID-5577
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Reporter: Steven Hawkins
> Assignee: Van Halbert
> Priority: Major
>
> The teiid-bom currently defines all of the non-overlapping dependencies with the wildfly bom.
> We should introduce another bom that defines the overlapping dependencies used by the core project - this includes things like vfs, jboss-logging, the javax api jars, marshalling, infinispan, etc. We should also substitute usage of the jboss javax jars for whatever the vanilla replacements are.
> We should then be able to cut ties with wildfly boms in the core project.
> For connector development convenience we could also introduce a bom-wildfly which imports both the teiid-bom and the wildfly-parent.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5583) Provide ability to monitor how much memory matviews are using
by Colin Mondesir (Jira)
Colin Mondesir created TEIID-5583:
-------------------------------------
Summary: Provide ability to monitor how much memory matviews are using
Key: TEIID-5583
URL: https://issues.jboss.org/browse/TEIID-5583
Project: Teiid
Issue Type: Enhancement
Reporter: Colin Mondesir
Assignee: Steven Hawkins
In the docs it says "Internal materialization (and temp tables in general) have memory overhead for each page. A rough guideline is that there can be 100 million rows in all materialized tables across all VDBs for every gigabyte of heap."
But we have no feature that allows us to monitor how exactly how much memory matviews are actually using, this makes adjusting the heap to match changing requirement difficult.
--
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,
thank you very much for your help. I was also thinking to complicated :) As I have everything in containers already it is quite easy to have two instances of the server running in parallel. Hence I will only patch the 11.x version for the moment.
Regarding Q2: Should I let the patch file in, or should I remove it from modules.xml? If I understand you correctly it should not matter and both options are good to go?
> 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 Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIID-5545?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5545:
-------------------------------------
If you want the Teiid 9.x working the simplest is to grab the Olingo 4.2 and apply my fix on top of it locally on your code and use that. I did not think of that before ;)
Q2) Yes, you can ignore patches. I do not see any code there.
Q3) if we not changing the versions i.e working with 4.2 on the Teiid 9.x, 4.5 on the 11.x you do not need to mess with any dependencies.
> 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,
as things again do not seem to get trivial, I thought the Jira here might be the wrong place to proceed with the discussion. I therefore opened a new topic here. Please have a look at it.
https://developer.jboss.org/message/987212#987212
Maybe the first topic regarding Teiid 9.x and Olingo 4.2 is more easy to solve than I thought
Regarding Q2: In Teiid 11 also such a patch file teiid-olingo-patches-11.2.0.jar exists. Do you think this can be safely ignored? Should I leave it in or remove it from the modules.xml?
Q3: The modules xml unfortuntely says only what dependencies are there, but not in which version numbers. I assume this is important as well, or am I wrong with this assumption?
<dependencies>
<module name="javax.api"/>
<module name="javax.servlet.api"/>
<module name="javax.xml.stream.api"/>
<module name="org.apache.httpcomponents"/>
<module name="com.fasterxml.jackson.core.jackson-core"/>
<module name="com.fasterxml.jackson.core.jackson-annotations"/>
<module name="com.fasterxml.jackson.core.jackson-databind"/>
<module name="com.fasterxml.aalto-xml"/>
<module name="org.apache.olingo.commons"/>
<module name="org.apache.commons.codec"/>
</dependencies>
> 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-5563) Separate the Teiid WildFly distribution into their own repo or module
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5563:
---------------------------------------
> (1) one involves many pom changes, 4 will result in a lot of doc changes I think.
We can do this in two phases if that makes sense - Teiid 12 reorg and propose new module names, then change things in 13. The only things that have actually changed in the coordinates at this point are the wildfly kit artifacts.
> 1) It seems appropriate to introduce the "org.teiid.wildfly" as groupid for any projects underneath "wildfly" module.
This for example will look like org.teiid.wildfly:teiid-wildfly-admin
> 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.
I'm fine with leaving them as they are - especially if we do 4. Connector is the common name for resource adapter.
> 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.
Yes this is the change that clarifies things the most.
> 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-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:
-------------------------------------
For 9.x Teiid, Olingo from going to 4.2 to 4.5+ I know there are many changes, so simple replacement will not work. You can probably do this only for 11.2 without much hassle. What you show seem as correct list.
Q2: for 4.2 we did some overrides there, so it may not be there in later versions.
Q3: when you look at maven list vs what is in the module.xml file shows as dependencies for each jar/module.
> 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-5582) xml format option is ignored by odata crossjoin
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5582:
-------------------------------------
Summary: xml format option is ignored by odata crossjoin
Key: TEIID-5582
URL: https://issues.jboss.org/browse/TEIID-5582
Project: Teiid
Issue Type: Bug
Components: OData
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 12.1
Since we have a custom serializer that is only implemented for json, the use of a format option is ignored for cross join queries.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months