May 2020 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIIDSB-197) Add a module for each external source

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-197?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIIDSB-197: ---------------------------------------- > which I agree to needs improvement here, to remove driver versions from Operator And that is exactly what I'm proposing to address here... I'm not sure why I'm having such a hard time getting through to you on some of this :( > Another reason the driver versions designed this way was to override them if user wanted to use a different version. That should be completely discounted as a possibility. You can override dependencies in the crd's themselves to do it on an ad hoc basis in your own custom operator would make it extremely difficult to know what versions of things were actual in use. > I am reluctant to create 30 more projects with a single file to remove one config file Let me rephase that - you currently believe you can do as good of a job of dependency management as maven in a single file. However I would counter that once you encounter sources that need more than a single dependency and/or you need better traceability - then it would be best to just rely on a standard system. > I completely miss the point you are making with enviroment-post-processor, are saying no prefix needed at all? How am I passing the properties I configured for a data source to a SB process? even if it is, why add more complexity? As far as the operator is concerned, yes there is no Teiid Spring Boot specific prefix needed, just a general convention - then let Teiid Spring Boot convert the properties to the actual property. So for example default everything to spring.teiid.data.alias.property and let Teiid Spring Boot determine if it needs to actually be spring.datasource, spring.datasource.xa, etc. > Pretty soon, I also would like to add property names and then validate them when the CR is provided I get that as a goal. But keep in mind it's not as straight forward as it seems. There's a lot of pooling related properties that could be included, all of the XADataSource properties (which aren't explicitly named by spring), or other similar more free form / source driven properties. The more you commit to assumptions, the more rigid and brittle things will become (for example are we prepared to fully commit to a particular pooling implementation, or do we need to come up with abstractions). > Add a module for each external source > ------------------------------------- > > Key: TEIIDSB-197 > URL: https://issues.redhat.com/browse/TEIIDSB-197 > Project: Teiid Spring Boot > Issue Type: Enhancement > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > > To simplify the logic in the operator each external source should be represented by a maven artifact - org.teiid:spring-data-x. Any dependency management would be handled in that module and not in the operator - to remove the need for a config file containing driver versions. Additionally property handling should be moved into Teiid Spring Boot such that the operator does not need to know what property prefix is expected. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5944) Infinispan protobuf generation fails to validate name with "-" in them

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIID-5944?page=com.atlassian.jira.plugi... ] Ramesh Reddy commented on TEIID-5944: ------------------------------------- BTW, the "vdb-code-gen" does convert to underscore already. > Infinispan protobuf generation fails to validate name with "-" in them > ---------------------------------------------------------------------- > > Key: TEIID-5944 > URL: https://issues.redhat.com/browse/TEIID-5944 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Ramesh Reddy > Assignee: Steven Hawkins > Priority: Major > Fix For: 14.0 > > > When the name of the view contains like "mat-example_vix" the protobuf generation seems to succeed however the validation of it by the Infinispan seems to fail. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5944) Infinispan protobuf generation fails to validate name with "-" in them

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIID-5944?page=com.atlassian.jira.plugi... ] Ramesh Reddy resolved TEIID-5944. --------------------------------- Resolution: Rejected > Infinispan protobuf generation fails to validate name with "-" in them > ---------------------------------------------------------------------- > > Key: TEIID-5944 > URL: https://issues.redhat.com/browse/TEIID-5944 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Ramesh Reddy > Assignee: Steven Hawkins > Priority: Major > Fix For: 14.0 > > > When the name of the view contains like "mat-example_vix" the protobuf generation seems to succeed however the validation of it by the Infinispan seems to fail. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5944) Infinispan protobuf generation fails to validate name with "-" in them

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIID-5944?page=com.atlassian.jira.plugi... ] Ramesh Reddy commented on TEIID-5944: ------------------------------------- See https://developers.google.com/protocol-buffers/docs/reference/proto3-spec... under messageName with ident has a pattern {code} ident = letter { letter | decimalDigit | "_" } {code} so no dash/hiphen are allowed per spec. > Infinispan protobuf generation fails to validate name with "-" in them > ---------------------------------------------------------------------- > > Key: TEIID-5944 > URL: https://issues.redhat.com/browse/TEIID-5944 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Ramesh Reddy > Assignee: Steven Hawkins > Priority: Major > Fix For: 14.0 > > > When the name of the view contains like "mat-example_vix" the protobuf generation seems to succeed however the validation of it by the Infinispan seems to fail. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-197) Add a module for each external source

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-197?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIIDSB-197: -------------------------------------- I am not sure why you say it is an issue? it is externalized and fully automated, and in absence of missing configuration, it works exactly as you describe minus the driver versions (which I agree to needs improvement here, to remove driver versions from Operator). Another reason the driver versions designed this way was to override them if user wanted to use a different version. I am reluctant to create 30 more projects with a single file to remove one config file. The dependency part is attractive, but I have yet find solution for replacement with different versions. This is also going to be used probably with other toolings like vscode plugin, where I need types and properties. Pretty soon, I also would like to add property names and then validate them when the CR is provided Another issue I saw with Syndesis is, in Syndesis I was using URL sniffing to come up with what kind of source it is, I could easily add to this and provide that ability in the future, so it gives that flexibility rather than hide only behind the name-based patterns. > That however is also not necessary. Spring has property handling logic, Agree that, what I am saying even I have blank json file, it works as you say. This file iterates the same or lets you overwrite if you need to, for example, I used this for "soap" and "ws" where use prefix of soap for example. It gives flexibility and a single contract between the tools. > Essentially what I'm getting at is that the operator doesn't really need intimate or generated configuration to do it's job. How should pass the configuration? I completely miss the point you are making with enviroment-post-processor, are saying no prefix needed at all? How am I passing the properties I configured for a data source to a SB process? even if it is, why add more complexity? > Add a module for each external source > ------------------------------------- > > Key: TEIIDSB-197 > URL: https://issues.redhat.com/browse/TEIIDSB-197 > Project: Teiid Spring Boot > Issue Type: Enhancement > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > > To simplify the logic in the operator each external source should be represented by a maven artifact - org.teiid:spring-data-x. Any dependency management would be handled in that module and not in the operator - to remove the need for a config file containing driver versions. Additionally property handling should be moved into Teiid Spring Boot such that the operator does not need to know what property prefix is expected. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-197) Add a module for each external source

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-197?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIIDSB-197: ---------------------------------------- > This is already done too, there is no particular logic about data sources in Operator, it is currently driven through the config file or given name in the CR. I guess the version number is still not, will see how to improve that! I don't think you follow me. I'm not specifically talking about code vs. configuration. Just the fact that the operator has knowledge like: https://github.com/teiid/teiid-operator/blob/master/build/conf/config.yaml is problematic. If you represented each jdbc source as a maven artifact, then those versions would be managed as maven dependencies. > This is already the case with the latest changes. That is not correct either. You mean to say that it is embedded in the generated json file https://github.com/teiid/teiid-operator/blob/01dd29e95e14ba2dcbc5e750bb9d... That however is also not necessary. Spring has property handling logic, for example https://www.baeldung.com/spring-boot-environmentpostprocessor, that would allow you modify the env properties as needed on startup before they are consumed by other components. Essentially what I'm getting at is that the operator doesn't really need intimate or generated configuration to do it's job. > Add a module for each external source > ------------------------------------- > > Key: TEIIDSB-197 > URL: https://issues.redhat.com/browse/TEIIDSB-197 > Project: Teiid Spring Boot > Issue Type: Enhancement > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > > To simplify the logic in the operator each external source should be represented by a maven artifact - org.teiid:spring-data-x. Any dependency management would be handled in that module and not in the operator - to remove the need for a config file containing driver versions. Additionally property handling should be moved into Teiid Spring Boot such that the operator does not need to know what property prefix is expected. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-197) Add a module for each external source

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-197?page=com.atlassian.jira.plug... ] Ramesh Reddy edited comment on TEIIDSB-197 at 5/7/20 12:08 PM: --------------------------------------------------------------- > Any dependency management would be handled in that module and not in the operator This is already done too, there is no particular logic about data sources in Operator, it is currently driven through the config file or given name in the CR. I guess the version number is still not, will see how to improve that! > Additionally property handling should be moved into Teiid Spring Boot such that the operator does not need to know what property prefix is expected. This is already the case with the latest changes. was (Author: rareddy): > Any dependency management would be handled in that module and not in the operator This is already done too, there is no particular logic about data sources in Operator, it is currently driven through the config file or given name in the CR > Additionally property handling should be moved into Teiid Spring Boot such that the operator does not need to know what property prefix is expected. This is already the case with the latest changes. > Add a module for each external source > ------------------------------------- > > Key: TEIIDSB-197 > URL: https://issues.redhat.com/browse/TEIIDSB-197 > Project: Teiid Spring Boot > Issue Type: Enhancement > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > > To simplify the logic in the operator each external source should be represented by a maven artifact - org.teiid:spring-data-x. Any dependency management would be handled in that module and not in the operator - to remove the need for a config file containing driver versions. Additionally property handling should be moved into Teiid Spring Boot such that the operator does not need to know what property prefix is expected. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-197) Add a module for each external source

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-197?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIIDSB-197: -------------------------------------- > Any dependency management would be handled in that module and not in the operator This is already done too, there is no particular logic about data sources in Operator, it is currently driven through the config file or given name in the CR > Additionally property handling should be moved into Teiid Spring Boot such that the operator does not need to know what property prefix is expected. This is already the case with the latest changes. > Add a module for each external source > ------------------------------------- > > Key: TEIIDSB-197 > URL: https://issues.redhat.com/browse/TEIIDSB-197 > Project: Teiid Spring Boot > Issue Type: Enhancement > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Priority: Major > > To simplify the logic in the operator each external source should be represented by a maven artifact - org.teiid:spring-data-x. Any dependency management would be handled in that module and not in the operator - to remove the need for a config file containing driver versions. Additionally property handling should be moved into Teiid Spring Boot such that the operator does not need to know what property prefix is expected. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-198) Align with 2.2.6 spring boot

by Ramesh Reddy (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-198?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIIDSB-198: -------------------------------------- yeah, that is better, we should decouple from syndesis setting. > Align with 2.2.6 spring boot > ----------------------------- > > Key: TEIIDSB-198 > URL: https://issues.redhat.com/browse/TEIIDSB-198 > Project: Teiid Spring Boot > Issue Type: Task > Components: core > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 1.5.0 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Due to the wildfly updates of TEIID-5859 that pull in a newer cxf and related dependencies, we end up with version conflicts. The best fix seems to be bumping Teiid Spring Boot to a later version. The only downside is that later version of spring boot have switched to jakarta javax dependencies, so we get a lot of duplicate / different class warnings. We can ignore the errors/warning, try to exclude incoming dependencies from Teiid, or switch Teiid to use jakarta instead... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-198) Align with 2.2.6 spring boot

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-198?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIIDSB-198: ---------------------------------------- To decouple things, I'll work a separate issue to remove that or both spring boot version reference from the template pom. > Align with 2.2.6 spring boot > ----------------------------- > > Key: TEIIDSB-198 > URL: https://issues.redhat.com/browse/TEIIDSB-198 > Project: Teiid Spring Boot > Issue Type: Task > Components: core > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 1.5.0 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Due to the wildfly updates of TEIID-5859 that pull in a newer cxf and related dependencies, we end up with version conflicts. The best fix seems to be bumping Teiid Spring Boot to a later version. The only downside is that later version of spring boot have switched to jakarta javax dependencies, so we get a lot of duplicate / different class warnings. We can ignore the errors/warning, try to exclude incoming dependencies from Teiid, or switch Teiid to use jakarta instead... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 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 May 2020