[JBoss JIRA] (TEIID-5525) add a flag to revert to the prior behavior (TEIID-4557)
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5525?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5525:
---------------------------------------
Followed up with TEIID-5584 to default enforceSingleMaxBufferSizeEstimate to false upstream as well. Starting with 12.x we'll initially rely on intelligent session killing - but the user can enable this or the session maximum if they want more proactive enforcement.
> add a flag to revert to the prior behavior (TEIID-4557)
> -------------------------------------------------------
>
> Key: TEIID-5525
> URL: https://issues.jboss.org/browse/TEIID-5525
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.12.14.6_4, 8.12.15.6_4
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 11.0.3, 11.1.2, 12.0, 11.2.1, 8.12.17.6_4
>
>
> Several customers are seeing errors[1] after https://issues.jboss.org/browse/TEIID-4557 was implemented and generally have to drop the max-active-plans to 1 for their queries to succeed. Can a flag be added to revert to the behavior prior to TEIID-4557?
> [1]
> ERROR [org.teiid.PROCESSOR] TEIID30019 Unexpected exception for request rcX003UtoyEg.0: org.teiid.core.TeiidComponentException: TEIID31261 Max estimated size 4,963,628,721 for a single operation/table id 85 has been exceeded. The server may need to increase the amount of disk or memory available, or decrease the number of max active plans.
--
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 Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Van Halbert edited comment on TEIID-5563 at 1/8/19 10:32 AM:
-------------------------------------------------------------
Just an fyi:
Java 9 deprecated six modules that contain Java EE APIs:
java.activation with javax.activation package
java.corba with javax.activity, javax.rmi, javax.rmi.CORBA, and org.omg.* packages
java.transaction with javax.transaction package
java.xml.bind with all javax.xml.bind.* packages
java.xml.ws with javax.jws, javax.jws.soap, javax.xml.soap, and all javax.xml.ws.* packages
java.xml.ws.annotation with javax.annotation package
helpful thread: [https://stackoverflow.com/questions/48204141/replacements-for-deprecated-...]
was (Author: van.halbert):
Just an fyi:
Java 9 deprecated six modules that contain Java EE APIs:
java.activation with javax.activation package
java.corba with javax.activity, javax.rmi, javax.rmi.CORBA, and org.omg.* packages
java.transaction with javax.transaction package
java.xml.bind with all javax.xml.bind.* packages
java.xml.ws with javax.jws, javax.jws.soap, javax.xml.soap, and all javax.xml.ws.* packages
java.xml.ws.annotation with javax.annotation package
> 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-5563) Separate the Teiid WildFly distribution into their own repo or module
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5563:
------------------------------------
Just an fyi:
Java 9 deprecated six modules that contain Java EE APIs:
java.activation with javax.activation package
java.corba with javax.activity, javax.rmi, javax.rmi.CORBA, and org.omg.* packages
java.transaction with javax.transaction package
java.xml.bind with all javax.xml.bind.* packages
java.xml.ws with javax.jws, javax.jws.soap, javax.xml.soap, and all javax.xml.ws.* packages
java.xml.ws.annotation with javax.annotation package
> 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-5521) Add build plugins used by basepom to help with dependency handling
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5521:
------------------------------------
Have run into the following duplicate issue in several places:
{code}
[WARNING] Found duplicate (but equal) classes in [org.infinispan:infinispan-commons:9.3.1.Final, org.infinispan:infinispan-core:9.3.1.Final]:
[WARNING] org.infinispan.util.AbstractDelegatingCollection
[WARNING] org.infinispan.util.AbstractDelegatingConcurrentMap
[WARNING] org.infinispan.util.AbstractDelegatingMap
[WARNING] org.infinispan.util.AbstractDelegatingSet
[WARNING] Found duplicate and different resources in [org.infinispan:infinispan-commons:9.3.1.Final, org.infinispan:infinispan-core:9.3.1.Final]:
[WARNING] features.xml
[WARNING] Found duplicate classes/resources in compile classpath.
[WARNING] Found duplicate (but equal) classes in [org.infinispan:infinispan-commons:9.3.1.Final, org.infinispan:infinispan-core:9.3.1.Final]:
[WARNING] org.infinispan.util.AbstractDelegatingCollection
[WARNING] org.infinispan.util.AbstractDelegatingConcurrentMap
[WARNING] org.infinispan.util.AbstractDelegatingMap
[WARNING] org.infinispan.util.AbstractDelegatingSet
[WARNING] Found duplicate and different resources in [org.infinispan:infinispan-commons:9.3.1.Final, org.infinispan:infinispan-core:9.3.1.Final]:
[WARNING] features.xml
[WARNING] Found duplicate classes/resources in runtime classpath.
{code}
Need to figure out how to resolve this, but for now, in those projects setting property:
{code}
<basepom.check.skip-duplicate-finder>true</basepom.check.skip-duplicate-finder>
{code}
> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
> Key: TEIID-5521
> URL: https://issues.jboss.org/browse/TEIID-5521
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
> Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5521) Add build plugins used by basepom to help with dependency handling
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5521:
------------------------------------
Issue with olingo-patches. With the current pom, it errors with:
{code}
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-install-plugin:2.5.2:install (default-cli) on project teiid-olingo-patches: The packaging for this project did not assign a file to the build artifact ->
{code}
Tried suggestions of running install:install or jar:jar, but with no luck.
So then added a source code place holder so that it would build the jar: src/main/java/org/teiid/olingo/README.md, but then it fails with:
{code}
Unused declared dependencies found
{code}
I could comment out dependencies and it will build, that is an option. For now, locally, commenting out olingo-patches and moving on.
> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
> Key: TEIID-5521
> URL: https://issues.jboss.org/browse/TEIID-5521
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
> Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5555) Create OpenAPI (swagger) metadata document based on OData
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIID-5555?page=com.atlassian.jira.plugin... ]
Ramesh Reddy updated TEIID-5555:
--------------------------------
Comment: was deleted
(was: Sorry, was the wrong issue to which I added this comment. I unfortunately do not know how to delete it :()
> Create OpenAPI (swagger) metadata document based on OData
> ---------------------------------------------------------
>
> Key: TEIID-5555
> URL: https://issues.jboss.org/browse/TEIID-5555
> Project: Teiid
> Issue Type: Enhancement
> Components: OData
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Priority: Blocker
> Fix For: 12.1, 11.2.2
>
>
> Automatically generate Swagger metadata document based on OData metadata such the tools like 3Scale can understand the metadata through existing plugins until OData specific plugin is generated. Only swagger 2.0 document is considered for now. 3.0 support is not considered.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5588) Please add support for earlyRequest feature which is for example used in the OpenUI5 library to enhance performance in single page apps
by Christoph John (Jira)
[ https://issues.jboss.org/browse/TEIID-5588?page=com.atlassian.jira.plugin... ]
Christoph John updated TEIID-5588:
----------------------------------
Description:
As discussed in https://issues.jboss.org/browse/TEIID-5545 OpenUI5 implements a earlyRequest feature to preload metadata information from an odata v4 service. It would be great if support for this could be added to Teiid/Widlfly.
Thomas Chadzelek, who I assume is a lead developer for the odata v4 model at SAP kindly provided the following information and offered his support in case further questions arise:
The "earlyRequests" parameter is pretty simple. It will send GET requests for /$metadata and all annotation XML files (see parameter "annotationURI"). It will also send a HEAD request to with header "X-CSRF-Token" : "Fetch" in order to fetch the security token. If Teiid/Olingo does not implement CSRF protection by requiring such a header, there should be no need to properly answer the HEAD request at all. Else it would be nice to return the right CSRF token value in the response's headers.
Please see Cross-Site Request Forgery Protection and Gateway protection against Cross-Site Request Forgery attacks for some background infos.
For further questions you can contact him directly by joining the discussion at:
https://github.com/SAP/openui5/issues/2288
Thanks a lot. Let we know if I can support with testing.
Best regards,
Christoph
was:
As discussed in https://issues.jboss.org/browse/TEIID-5545 OpenUI5 implements a earlyRequest feature to preload metadata information from an odata v4 service. It would be great if support for this could be added to Teiid/Widlfly.
Thomas Chadzelek, who I assume is a lead developer for the odata v4 model kindly gave me the following information and offered his support if further questions arise:
The "earlyRequests" parameter is pretty simple. It will send GET requests for /$metadata and all annotation XML files (see parameter "annotationURI"). It will also send a HEAD request to with header "X-CSRF-Token" : "Fetch" in order to fetch the security token. If Teiid/Olingo does not implement CSRF protection by requiring such a header, there should be no need to properly answer the HEAD request at all. Else it would be nice to return the right CSRF token value in the response's headers.
Please see Cross-Site Request Forgery Protection and Gateway protection against Cross-Site Request Forgery attacks for some background infos.
For further questions you can contact him directly by joining the discussion at:
https://github.com/SAP/openui5/issues/2288
Thanks a lot. Let we know if I can support with testing.
Best regards,
Christoph
> Please add support for earlyRequest feature which is for example used in the OpenUI5 library to enhance performance in single page apps
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-5588
> URL: https://issues.jboss.org/browse/TEIID-5588
> Project: Teiid
> Issue Type: Enhancement
> Affects Versions: 11.2.1
> Reporter: Christoph John
> Assignee: Steven Hawkins
> Priority: Optional
>
> As discussed in https://issues.jboss.org/browse/TEIID-5545 OpenUI5 implements a earlyRequest feature to preload metadata information from an odata v4 service. It would be great if support for this could be added to Teiid/Widlfly.
> Thomas Chadzelek, who I assume is a lead developer for the odata v4 model at SAP kindly provided the following information and offered his support in case further questions arise:
> The "earlyRequests" parameter is pretty simple. It will send GET requests for /$metadata and all annotation XML files (see parameter "annotationURI"). It will also send a HEAD request to with header "X-CSRF-Token" : "Fetch" in order to fetch the security token. If Teiid/Olingo does not implement CSRF protection by requiring such a header, there should be no need to properly answer the HEAD request at all. Else it would be nice to return the right CSRF token value in the response's headers.
> Please see Cross-Site Request Forgery Protection and Gateway protection against Cross-Site Request Forgery attacks for some background infos.
> For further questions you can contact him directly by joining the discussion at:
> https://github.com/SAP/openui5/issues/2288
> Thanks a lot. Let we know if I can support with testing.
> Best regards,
> Christoph
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5555) Create OpenAPI (swagger) metadata document based on OData
by Christoph John (Jira)
[ https://issues.jboss.org/browse/TEIID-5555?page=com.atlassian.jira.plugin... ]
Christoph John edited comment on TEIID-5555 at 1/7/19 4:57 PM:
---------------------------------------------------------------
Sorry, was the wrong issue to which I added this comment. I unfortunately do not know how to delete it :(
was (Author: cjohn001):
Hello Ramesh,
in the meantime I got detailed feedback regarding the earlyRequest feature. I added a Jira issue for it:
https://issues.jboss.org/browse/TEIID-5588
Thanks for having a look at it!
Best regards,
Christoph
> Create OpenAPI (swagger) metadata document based on OData
> ---------------------------------------------------------
>
> Key: TEIID-5555
> URL: https://issues.jboss.org/browse/TEIID-5555
> Project: Teiid
> Issue Type: Enhancement
> Components: OData
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Priority: Blocker
> Fix For: 12.1, 11.2.2
>
>
> Automatically generate Swagger metadata document based on OData metadata such the tools like 3Scale can understand the metadata through existing plugins until OData specific plugin is generated. Only swagger 2.0 document is considered for now. 3.0 support is not considered.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months