January 2020 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5881) Remove the alias cache logic from the infinispan translator

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIID-5881?page=com.atlassian.jira.plugi... ] Ramesh Reddy commented on TEIID-5881: ------------------------------------- I thought we did the alias logic only in a product branch, maybe wrong.. > Remove the alias cache logic from the infinispan translator > ----------------------------------------------------------- > > Key: TEIID-5881 > URL: https://issues.redhat.com/browse/TEIID-5881 > Project: Teiid > Issue Type: Quality Risk > Components: Infinispan > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 13.1, 13.0.2 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > We need to start with a deprecation in 13.0.2, then consider removal in 13.1. The docs will need updated as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5881) Remove the alias cache logic from the infinispan translator

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIID-5881?page=com.atlassian.jira.plugi... ] Steven Hawkins reassigned TEIID-5881: ------------------------------------- Description: We need to start with a deprecation in 13.0.2, then consider removal in 13.1. The docs will need updated as well. Original Estimate: 2 hours Remaining Estimate: 2 hours Assignee: Steven Hawkins (was: Ramesh Reddy) > Remove the alias cache logic from the infinispan translator > ----------------------------------------------------------- > > Key: TEIID-5881 > URL: https://issues.redhat.com/browse/TEIID-5881 > Project: Teiid > Issue Type: Quality Risk > Components: Infinispan > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 13.1, 13.0.2 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > We need to start with a deprecation in 13.0.2, then consider removal in 13.1. The docs will need updated as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5881) Remove the alias cache logic from the infinispan translator

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5881: ------------------------------------- Summary: Remove the alias cache logic from the infinispan translator Key: TEIID-5881 URL: https://issues.redhat.com/browse/TEIID-5881 Project: Teiid Issue Type: Quality Risk Components: Infinispan Reporter: Steven Hawkins Assignee: Ramesh Reddy Fix For: 13.1, 13.0.2 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5874) Infinispan connection should support a transactional cache

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIID-5874?page=com.atlassian.jira.plugi... ] Steven Hawkins updated TEIID-5874: ---------------------------------- Fix Version/s: 13.1 (was: 13.x) Original Estimate: 5 hours Remaining Estimate: 5 hours > Infinispan connection should support a transactional cache > ---------------------------------------------------------- > > Key: TEIID-5874 > URL: https://issues.redhat.com/browse/TEIID-5874 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Steven Hawkins > Priority: Major > Fix For: 13.1 > > Original Estimate: 5 hours > Remaining Estimate: 5 hours > > The configuration should allow for single phase commit and non-recoverable xa. This will need to change the transaction support on the translator, set the transaction config, and register a transactionManager lookup that can find the configured transaction manager. > The infinispan operator does not provide a way to configure the transaction support of the cache, so this may not fully work yet - I'll test to see what happens both with the default cache and with trying to create one on demand. -- 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: ---------------------------------------- > Does this mean we are going need our own JDG cluster, instead of using an existing one? For the purposes of the example, we'll own/create the DataGrid cluster. > I prefer we use an existing one, it will be better in terms of management aspects of it. That's why I'm still leaving this open. At some point, probably soon, we'll want to use their credentials. It's probably worth reaching out to the infinispan folks to see how they expect OpenShift clients to utilize their secret in a more automated way. Their docs show using oc and some extraction logic, but of course that's not how we'd expect this to work. > 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 > Time Spent: 2 hours > Remaining Estimate: 3 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 Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-157?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIIDSB-157: -------------------------------------- Does this mean we are going need our own JDG cluster, instead of using an existing one? I prefer we use an existing one, it will be better in terms of management aspects of it. > 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 > Time Spent: 2 hours > Remaining Estimate: 3 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] (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 commented on TEIID-5880: ------------------------------------- [~rhn-engineering-vhalbert] created branch https://github.com/teiid/oreva/tree/1.1.x for Java 11, but I could do a new release of the library 1.1.0 due to my failed attempt login into jboss nexus. I forgot if this closed now or something? > 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 > > 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 Van Halbert (Jira)

[ https://issues.redhat.com/browse/TEIID-5880?page=com.atlassian.jira.plugi... ] Van Halbert updated TEIID-5880: ------------------------------- Fix Version/s: (was: 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: Ramesh Reddy > Priority: Major > > 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] (TEIIDSB-154) Create an example of materialization with JDG on openshift

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-154?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIIDSB-154: ---------------------------------------- Other than the nice to have TEIIDSB-162 and the pending pr https://github.com/teiid/teiid-spring-boot/pull/175 it looks like this now works. A pr should be available today. > Create an example of materialization with JDG on openshift > ---------------------------------------------------------- > > Key: TEIIDSB-154 > URL: https://issues.redhat.com/browse/TEIIDSB-154 > Project: Teiid Spring Boot > Issue Type: Sub-task > Components: documentation, examples > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 1.3.1 > > Original Estimate: 1 day, 7 hours > Time Spent: 4 hours > Remaining Estimate: 1 day, 3 hours > > Create an example showing materialization with JDG on openshift. -- 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?focusedWorklogId=12449930&pa... ] Steven Hawkins logged work on TEIIDSB-157: ------------------------------------------ Author: Steven Hawkins Created on: 21/Jan/20 11:58 AM Start Date: 21/Jan/20 11:58 AM Worklog Time Spent: 2 hours Issue Time Tracking ------------------- Remaining Estimate: 3 hours (was: 5 hours) Time Spent: 2 hours Worklog Id: (was: 12449930) > 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 > Time Spent: 2 hours > Remaining Estimate: 3 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues January 2020