January 2020 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIIDSB-157) Support loading password credential from infinispan secret

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-157?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIIDSB-157: ----------------------------------- Original Estimate: 5 hours Remaining Estimate: 5 hours > Support loading password credential from infinispan secret > ---------------------------------------------------------- > > Key: TEIIDSB-157 > URL: https://issues.redhat.com/browse/TEIIDSB-157 > Project: Teiid Spring Boot > Issue Type: Sub-task > Components: datasource > Reporter: Steven Hawkins > Priority: Major > Fix For: 1.4.0 > > Original Estimate: 5 hours > Remaining Estimate: 5 hours > > The infinispan operator generates a secret that contains a yaml file, which is where the developer password is stored. > There three approaches: > 1. for materialization assume that we will "own" the DataGrid instance such that we'll create and pass our own secret file for infinispan to use. In this case we'll know the password and can provide that to the connection factory via an env property. > 2. add logic to the connection factory to specify a "credential file" such that we'll parse the yaml from the given location (a mount of the secret) and find the appropriate credential for the given username (typically developer). > 3. ask the infinispan team to allow for easier consumption of the secret (a secret per user?) > To get things working with the example, I can take the first approach - but it will look a little convoluted. > In general 2 or 3 will be needed in scenarios where we expect to simply pick up existing credentials. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-157) Support loading password credential from infinispan secret

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-157?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIIDSB-157: ----------------------------------- Fix Version/s: (was: 1.3.1) > Support loading password credential from infinispan secret > ---------------------------------------------------------- > > Key: TEIIDSB-157 > URL: https://issues.redhat.com/browse/TEIIDSB-157 > Project: Teiid Spring Boot > Issue Type: Sub-task > Components: datasource > Reporter: Steven Hawkins > Priority: Major > Fix For: 1.4.0 > > > The infinispan operator generates a secret that contains a yaml file, which is where the developer password is stored. > There three approaches: > 1. for materialization assume that we will "own" the DataGrid instance such that we'll create and pass our own secret file for infinispan to use. In this case we'll know the password and can provide that to the connection factory via an env property. > 2. add logic to the connection factory to specify a "credential file" such that we'll parse the yaml from the given location (a mount of the secret) and find the appropriate credential for the given username (typically developer). > 3. ask the infinispan team to allow for easier consumption of the secret (a secret per user?) > To get things working with the example, I can take the first approach - but it will look a little convoluted. > In general 2 or 3 will be needed in scenarios where we expect to simply pick up existing credentials. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-157) Support loading password credential from infinispan secret

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-157?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIIDSB-157: ---------------------------------------- It turns out that the doc link above is out of date. It should reference the property endpointSecretName. With that change Option 1 now works. This will be left open for now though until we determine if we'll need to generally re-use rather than set the credentials for infinispan. > Support loading password credential from infinispan secret > ---------------------------------------------------------- > > Key: TEIIDSB-157 > URL: https://issues.redhat.com/browse/TEIIDSB-157 > Project: Teiid Spring Boot > Issue Type: Sub-task > Components: datasource > Reporter: Steven Hawkins > Priority: Major > Fix For: 1.4.0, 1.3.1 > > > The infinispan operator generates a secret that contains a yaml file, which is where the developer password is stored. > There three approaches: > 1. for materialization assume that we will "own" the DataGrid instance such that we'll create and pass our own secret file for infinispan to use. In this case we'll know the password and can provide that to the connection factory via an env property. > 2. add logic to the connection factory to specify a "credential file" such that we'll parse the yaml from the given location (a mount of the secret) and find the appropriate credential for the given username (typically developer). > 3. ask the infinispan team to allow for easier consumption of the secret (a secret per user?) > To get things working with the example, I can take the first approach - but it will look a little convoluted. > In general 2 or 3 will be needed in scenarios where we expect to simply pick up existing credentials. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-162) vdb codegen does not account for the transaction manager

by Steven Hawkins (Jira)

Steven Hawkins created TEIIDSB-162: -------------------------------------- Summary: vdb codegen does not account for the transaction manager Key: TEIIDSB-162 URL: https://issues.redhat.com/browse/TEIIDSB-162 Project: Teiid Spring Boot Issue Type: Sub-task Components: OpenShift Reporter: Steven Hawkins Assignee: Ramesh Reddy Fix For: 1.4.0 If you define a vdb in a cr, the generated vdb will just use the platformtransactionmanager. Since the materialization procedures use transaction blocks, we need a full transaction manager. By default with the platformtransactionmanager it will throw an exception - only spring managed transactions ... The workaround would be to add snowdrop to the cr dependencies, but it would be nice to either always use that in the generated, or detect materialization is being used, or address TEIIDSB-109 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-160) Initialization order issue

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-160?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIIDSB-160. ------------------------------------ Resolution: Done Applied to master and 7.6. Now that we have both a before and after configure we should have just a narrow window for the teiid auto configuration - after the jta transaction manager is installed, but before the default data source is configured. > Initialization order issue > -------------------------- > > Key: TEIIDSB-160 > URL: https://issues.redhat.com/browse/TEIIDSB-160 > Project: Teiid Spring Boot > Issue Type: Bug > Components: core > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 1.4.0, 1.3.1 > > Original Estimate: 2 hours > Time Spent: 2 hours > Remaining Estimate: 0 minutes > > In working with the infinispan translator there is a situation where defining a project that has no relational sources, but uses infinispan and a rest source on startup gives: > {code} > Description: > The bean 'dataSource', defined in class path resource [org/teiid/spring/autoconfigure/TeiidAutoConfiguration.class], could not be registered. A bean with that name has already been defined in class path resource [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Tomcat.class] and overriding is disabled. > Action: > Consider renaming one of the beans or enabling overriding by setting spring.main.allow-bean-definition-overriding=true > {code} > Our starter has a reference to tomcat-jdbc, so that will always be in the classpath making that DataSourceConfiguration eligible. > The best solution seems to be for the TeiidAutoConfiguration to be marked with {code}@AutoConfigureBefore({ DataSourceAutoConfiguration.class }){code} so that it will install the primary datasource bean first. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5880) Oreva fails when built with jdk11

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIID-5880?page=com.atlassian.jira.plugi... ] Ramesh Reddy reassigned TEIID-5880: ----------------------------------- Assignee: Ramesh Reddy (was: Steven Hawkins) > Oreva fails when built with jdk11 > --------------------------------- > > Key: TEIID-5880 > URL: https://issues.redhat.com/browse/TEIID-5880 > Project: Teiid > Issue Type: Bug > Components: Build/Kits > Reporter: Van Halbert > Assignee: Ramesh Reddy > Priority: Major > Fix For: 13.1 > > > Oreva, master branch, fails when built with jdk11. > Error: > {code} > ERROR] /home/vhalbert/RedHat/github/product_branches/teiidrepos/oreva/odata-core/src/main/java/org/odata4j/stax2/staximpl/StaxXMLWriter2.java:[74,36] no suitable method found for createStartElement(javax.xml.namespace.QName,<nulltype>,java.util.Iterator<capture#2 of ?>) > method javax.xml.stream.XMLEventFactory.createStartElement(javax.xml.namespace.QName,java.util.Iterator<? extends javax.xml.stream.events.Attribute>,java.util.Iterator<? extends javax.xml.stream.events.Namespace>) is not applicable > (argument mismatch; java.util.Iterator<capture#2 of ?> cannot be converted to java.util.Iterator<? extends javax.xml.stream.events.Namespace>) > method javax.xml.stream.XMLEventFactory.createStartElement(java.lang.String,java.lang.String,java.lang.String) is not applicable > (argument mismatch; javax.xml.namespace.QName cannot be converted to java.lang.String) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5880) Oreva fails when built with jdk11

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIID-5880?page=com.atlassian.jira.plugi... ] Ramesh Reddy updated TEIID-5880: -------------------------------- Fix Version/s: 13.1 > Oreva fails when built with jdk11 > --------------------------------- > > Key: TEIID-5880 > URL: https://issues.redhat.com/browse/TEIID-5880 > Project: Teiid > Issue Type: Bug > Components: Build/Kits > Reporter: Van Halbert > Assignee: Steven Hawkins > Priority: Major > Fix For: 13.1 > > > Oreva, master branch, fails when built with jdk11. > Error: > {code} > ERROR] /home/vhalbert/RedHat/github/product_branches/teiidrepos/oreva/odata-core/src/main/java/org/odata4j/stax2/staximpl/StaxXMLWriter2.java:[74,36] no suitable method found for createStartElement(javax.xml.namespace.QName,<nulltype>,java.util.Iterator<capture#2 of ?>) > method javax.xml.stream.XMLEventFactory.createStartElement(javax.xml.namespace.QName,java.util.Iterator<? extends javax.xml.stream.events.Attribute>,java.util.Iterator<? extends javax.xml.stream.events.Namespace>) is not applicable > (argument mismatch; java.util.Iterator<capture#2 of ?> cannot be converted to java.util.Iterator<? extends javax.xml.stream.events.Namespace>) > method javax.xml.stream.XMLEventFactory.createStartElement(java.lang.String,java.lang.String,java.lang.String) is not applicable > (argument mismatch; javax.xml.namespace.QName cannot be converted to java.lang.String) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5878) Support loading the protobuf file from the classpath

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIID-5878?page=com.atlassian.jira.plugi... ] Ramesh Reddy resolved TEIID-5878. --------------------------------- Fix Version/s: 13.1 Resolution: Done > Support loading the protobuf file from the classpath > ---------------------------------------------------- > > Key: TEIID-5878 > URL: https://issues.redhat.com/browse/TEIID-5878 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > Fix For: 13.1, 13.0.2 > > Time Spent: 1 hour > Remaining Estimate: 0 minutes > > Providing a protobuf file should support loading from the classpath as well - currently it expects just a file system path. > This will allow for inclusion of protobuf files in Teiid Spring Boot fat jars. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5878) Support loading the protobuf file from the classpath

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIID-5878?page=com.atlassian.jira.plugi... ] Work on TEIID-5878 started by Ramesh Reddy. ------------------------------------------- > Support loading the protobuf file from the classpath > ---------------------------------------------------- > > Key: TEIID-5878 > URL: https://issues.redhat.com/browse/TEIID-5878 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > Fix For: 13.1, 13.0.2 > > Time Spent: 1 hour > Remaining Estimate: 0 minutes > > Providing a protobuf file should support loading from the classpath as well - currently it expects just a file system path. > This will allow for inclusion of protobuf files in Teiid Spring Boot fat jars. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-158) Salesforce connection factory uses a single connection

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-158?page=com.atlassian.jira.plug... ] Ramesh Reddy resolved TEIIDSB-158. ---------------------------------- Resolution: Done > Salesforce connection factory uses a single connection > ------------------------------------------------------ > > Key: TEIIDSB-158 > URL: https://issues.redhat.com/browse/TEIIDSB-158 > Project: Teiid Spring Boot > Issue Type: Bug > Components: datasource > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > Fix For: 1.4.0, 1.3.1 > > Time Spent: 1 hour > Remaining Estimate: 0 minutes > > The current salesforce connection factory creates just a single connection. However the connection object is not thread-safe - setting query options, etc. > Also if and when credential delegation is turned on we'll need separate connections as well so that everything is not run over a single session. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues January 2020