[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)
4 years, 7 months
[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)
4 years, 7 months
[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)
4 years, 7 months
[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)
4 years, 7 months
[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)
4 years, 7 months
[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)
4 years, 7 months
[JBoss JIRA] (TEIIDSB-192) Document migration for alias names
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-192?focusedWorklogId=12450976&pa... ]
Steven Hawkins logged work on TEIIDSB-192:
------------------------------------------
Author: Steven Hawkins
Created on: 07/May/20 9:27 AM
Start Date: 07/May/20 9:27 AM
Worklog Time Spent: 2 hours
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 2 hours)
Time Spent: 4 hours (was: 2 hours)
Worklog Id: (was: 12450976)
> Document migration for alias names
> ----------------------------------
>
> Key: TEIIDSB-192
> URL: https://issues.redhat.com/browse/TEIIDSB-192
> Project: Teiid Spring Boot
> Issue Type: Task
> Components: documentation
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 1.5.0
>
> Original Estimate: 4 hours
> Time Spent: 4 hours
> Remaining Estimate: 0 minutes
>
> Translators like salesforce and actian-vector has new name in the spring boot, we need to either document or switch back to original names.
> Also if we are updating migration utilities we can build in smarts into it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months