[JBoss JIRA] (TEIID-5574) Clarify buffer manager property names
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5574?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5574:
---------------------------------------
I took a pass through the cli and and EngineStatisticsBean with https://github.com/teiid/teiid/pull/1112
The EmbeddedConfiguration other than deprecations has not been modified - I'm a little fuzzy on whether you even want that at this point.
The only thing this breaks is older cli that configure the buffer service. Older config xml will still parse correctly. I went down the rabbit hole of how to do that correctly and only started at looking at the attribute transformation stuff before deciding it wasn't worth it.
[~rareddy] what do you think?
> Clarify buffer manager property names
> -------------------------------------
>
> Key: TEIID-5574
> URL: https://issues.jboss.org/browse/TEIID-5574
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine, Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.0
>
>
> Where possible the buffer manager properties should be better differentiated. Instead of max-buffer-space for example, we could have max-buffer-disk-space-mb.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (TEIID-5577) Create clean dependencies / separate boms
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5577?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5577:
---------------------------------------
> So the next step is TEIID-5563 and splitting out wildfly into its own bom and submodule section?
We are now shooting for:
org.teiid:teiid-bom - just teiid core / translator dependencies including overlap with wildfly
org.teiid:teiid-parent - imports the teiid-bom
org.teiid:teiid-wildfly-parent - imports the teiid-bom and wildfly parents and is the parent for stuff under the wildfly module
So just a parent teiid-wildfly-parent that aggregates, no need for a separate bom.
Part of the thinking behind removing the separate overlap bom is that at the end of this process we could entertain just collapsing the teiid-bom, teiid-build-configuration-parent, and teiid-parent back into just the teiid-parent.
> Create clean dependencies / separate boms
> -----------------------------------------
>
> Key: TEIID-5577
> URL: https://issues.jboss.org/browse/TEIID-5577
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Reporter: Steven Hawkins
> Assignee: Van Halbert
> Priority: Major
>
> The teiid-bom currently defines all of the non-overlapping dependencies with the wildfly bom.
> We should introduce another bom that defines the overlapping dependencies used by the core project - this includes things like vfs, jboss-logging, the javax api jars, marshalling, infinispan, etc. We should also substitute usage of the jboss javax jars for whatever the vanilla replacements are.
> We should then be able to cut ties with wildfly boms in the core project.
> For connector development convenience we could also introduce a bom-wildfly which imports both the teiid-bom and the wildfly-parent.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (TEIID-5577) Create clean dependencies / separate boms
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5577?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5577:
------------------------------------
So the next step is TEIID-5563 and splitting out wildfly into its own bom and submodule section?
> Create clean dependencies / separate boms
> -----------------------------------------
>
> Key: TEIID-5577
> URL: https://issues.jboss.org/browse/TEIID-5577
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Reporter: Steven Hawkins
> Assignee: Van Halbert
> Priority: Major
>
> The teiid-bom currently defines all of the non-overlapping dependencies with the wildfly bom.
> We should introduce another bom that defines the overlapping dependencies used by the core project - this includes things like vfs, jboss-logging, the javax api jars, marshalling, infinispan, etc. We should also substitute usage of the jboss javax jars for whatever the vanilla replacements are.
> We should then be able to cut ties with wildfly boms in the core project.
> For connector development convenience we could also introduce a bom-wildfly which imports both the teiid-bom and the wildfly-parent.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[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:
------------------------------------
With the removal of the wildfly related dependencies from the core build, there are numerous dependencies that the engine, runtime, olingo, rest-service, etc. are now missing. So I assume this is the part about managing the duplicate dependencies, because all these will need to be added to the "teiid-jboss-bom"?
> 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)
6 years, 1 month
[JBoss JIRA] (TEIID-5574) Clarify buffer manager property names
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIID-5574?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5574:
-------------------------------------
> Can you clarify that you currently map the spring config to the EmbeddedConfiguration
I have only exposed one or two properties so far. If user really wants their own configuration in Spring Boot they can simply provide an instance of `EmbeddedConfiguration` as in
{code}
@Bean
@Primary
EmbeddedConfiguration myconfig() {
return new EmbeddedConfiguration();
}
{code}
Only in the case they do not provide I take defaults mostly along with spring's approach of what are mostly right values to set?
> but it seems just as easy to just add handling for both and deprecate the old
I do not know any other way than this :(
> Or perhaps skip the cli entirely and let system / env properties supersede?
+1, It may be little confusing for WildFly user, but will avoid whole lot of crud work and work fine in embedded situation. Given my reluctance for WF, I am Ok with it.
> Clarify buffer manager property names
> -------------------------------------
>
> Key: TEIID-5574
> URL: https://issues.jboss.org/browse/TEIID-5574
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine, Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.0
>
>
> Where possible the buffer manager properties should be better differentiated. Instead of max-buffer-space for example, we could have max-buffer-disk-space-mb.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (TEIID-5577) Create clean dependencies / separate boms
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5577?page=com.atlassian.jira.plugin... ]
Work on TEIID-5577 stopped by Van Halbert.
------------------------------------------
> Create clean dependencies / separate boms
> -----------------------------------------
>
> Key: TEIID-5577
> URL: https://issues.jboss.org/browse/TEIID-5577
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Reporter: Steven Hawkins
> Assignee: Van Halbert
> Priority: Major
>
> The teiid-bom currently defines all of the non-overlapping dependencies with the wildfly bom.
> We should introduce another bom that defines the overlapping dependencies used by the core project - this includes things like vfs, jboss-logging, the javax api jars, marshalling, infinispan, etc. We should also substitute usage of the jboss javax jars for whatever the vanilla replacements are.
> We should then be able to cut ties with wildfly boms in the core project.
> For connector development convenience we could also introduce a bom-wildfly which imports both the teiid-bom and the wildfly-parent.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month