[JBoss JIRA] (TEIID-3825) Add a wildfly-swarm-teiid Fraction for running teiid as an uberjar
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3825?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3825:
-------------------------------------
This is not about running Teiid in Uber JAR, but how we integrate with WildFly Swarm in bringing services like transactions, data sources and security. In the end it would be exactly like Embedded but some of the services pre-filled in.
> Add a wildfly-swarm-teiid Fraction for running teiid as an uberjar
> ------------------------------------------------------------------
>
> Key: TEIID-3825
> URL: https://issues.jboss.org/browse/TEIID-3825
> Project: Teiid
> Issue Type: Feature Request
> Components: Embedded
> Affects Versions: 9.0
> Reporter: Kylin Soong
> Assignee: Kylin Soong
> Fix For: 9.x
>
>
> Fractions within WildFly Swarm are roughly equivalent to subsystems within WildFly, we have teiid subsystem in Server mode, so I think a Fraction is necessary to run teiid with Swarm.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (TEIID-3462) Add support for semantic versioning of VDBs
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3462?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3462:
-------------------------------------
>I think what will come out of this is that the notion of a semantic version will be part of the vdb name
Can you give an example here? is like "foo-1.2.3.vdb" where "foo-1.2.3" is the VDB name, and there is no notion of version. version is/will be always say "1"?
Another question I have is, how are these handled other data sources, RDBMS or otherwise? Is this specific only to Teiid? after all all we are saying is this is a version of metadata/schema?
> Add support for semantic versioning of VDBs
> -------------------------------------------
>
> Key: TEIID-3462
> URL: https://issues.jboss.org/browse/TEIID-3462
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.7
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> Semantic versioning [1] should be supported in the VDB versioning in order to be able to easier determine whether there are breaking changes from the client perspective and to more easily establish a link between client software versions and the VDBs they rely upon.
> [1] http://semver.org/
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (TEIID-3462) Add support for semantic versioning of VDBs
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3462?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3462:
---------------------------------------
> This I like, but my argument is why not push them towards a 3 or 6 digit number in version, which gives same features without any changes?
An encoded version is somewhat limiting in numeric range and does not support qualifiers, so it's not quite the same feature wise and does require some additional metadata for backwards compatibility.
> To me this is just a "made up" requirement, that does not really provide any advantages
I don't agree. The current notion of vdb version is really a revision and makes more sense as a internal construct. To promote something that is part of the api or connection level around a version should be more general / aligned to user concepts of versioning.
So I think what will come out of this is that the notion of a semantic version will be part of the vdb name and that the old vdb version / revision will stick around for a while for backwards compatibility and be optional. It looks like the changes to do that will be minimally scoped.
> Add support for semantic versioning of VDBs
> -------------------------------------------
>
> Key: TEIID-3462
> URL: https://issues.jboss.org/browse/TEIID-3462
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.7
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> Semantic versioning [1] should be supported in the VDB versioning in order to be able to easier determine whether there are breaking changes from the client perspective and to more easily establish a link between client software versions and the VDBs they rely upon.
> [1] http://semver.org/
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (TEIID-3462) Add support for semantic versioning of VDBs
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3462?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3462:
-------------------------------------
> That is somewhat the effect of what I'm talking about with deprecating the version number, However it does make things awkward to have both concepts
I am not saying to deprecate current version number, nor I am saying making semantic version a first class feature, this is optional feature for select "few" users who want this feature. Disrupting all the other users based on this does not seem like good idea to me. We do not have clue how user's individual current work flows have used or not used current version system. Your comment about auto-increment makes logical sense, I remember from MM days once we tried the auto-increment of the version upon the deployment and that was failure, because it caused more confusion about what was the target version number allocated, how that can be communicated to the client etc and eventually that got removed.
>What I'm looking at here from an api perspective is that when the old vdbVersion is >= 1, then we expect the old behavior of just a simple vdb name, otherwise the vdb name should be >the full name / semantic version.
This I like, but my argument is why not push them towards a 3 or 6 digit number in version, which gives same features without any changes?
To me this is just a "made up" requirement, that does not really provide any advantages, the semantic version is always defined by a user and current scheme allows user in using the current revision in that way if they choose to do it. If you feel strongly that we need to move this direction, then the only option I would advocate is changing the version to string field, and leave everything as is, and the semantics of defining the version to the user completely as you were suggesting in previous comments.
> Add support for semantic versioning of VDBs
> -------------------------------------------
>
> Key: TEIID-3462
> URL: https://issues.jboss.org/browse/TEIID-3462
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.7
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> Semantic versioning [1] should be supported in the VDB versioning in order to be able to easier determine whether there are breaking changes from the client perspective and to more easily establish a link between client software versions and the VDBs they rely upon.
> [1] http://semver.org/
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (TEIID-3462) Add support for semantic versioning of VDBs
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3462?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3462:
---------------------------------------
> there is NOTHING we can do to validate the fact that a given minor version of VDB did follow the rules of semantic versioning
That is generally the case with all semantic versioning. Unless you have a full regression test suite / spec, you are always implicitly trusting the developers that they versioned appropriately.
> why not we introduce a VDB level property for semantic version, then map this to the "vdb-version", so in cases where we check version number like JDBC connection, odbc connection, Teiid can provide alternative/additional ways to connect using the semantic version. Provide an Admin function to get one version from other. We can also think about re-working "connection type" based on semantic version.
That is somewhat the effect of what I'm talking about with deprecating the version number. However it does make things awkward to have both concepts - a version/revision and a semantic version. Keeping the revision as the primary concept you would expect for example that a semantic version based deployment would have an option to auto-increment the old version/revision number. It seems best to move things in the direction of the semantic version while leaving backwards compatibility initially. What I'm looking at here from an api perspective is that when the old vdbVersion is >= 1, then we expect the old behavior of just a simple vdb name, otherwise the vdb name should be the full name / semantic version.
> Add support for semantic versioning of VDBs
> -------------------------------------------
>
> Key: TEIID-3462
> URL: https://issues.jboss.org/browse/TEIID-3462
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.7
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> Semantic versioning [1] should be supported in the VDB versioning in order to be able to easier determine whether there are breaking changes from the client perspective and to more easily establish a link between client software versions and the VDBs they rely upon.
> [1] http://semver.org/
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (TEIID-3462) Add support for semantic versioning of VDBs
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3462?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3462:
-------------------------------------
Let's take a step back, what are things we are trying to control with semantic versioning? I know caching (materialization, resultset, metadata, prepared plan) etc. But what is the real usecase for the user? why one is favoring existing way over the other?
The JIRA lists as way to define "Type of Release" of the VDB, so that downstream client applications know that the VDB developer did or did not introduced the breaking changes inside the VDB metadata. IMO, there is NOTHING we can do to validate the fact that a given minor version of VDB did follow the rules of semantic versioning, thus I feel it does little advantage for teiid for taking such massive changes and breaking changes.
The suggestions I have is,
- why not we introduce a VDB level property for semantic version, then map this to the "vdb-version", so in cases where we check version number like JDBC connection, odbc connection, Teiid can provide alternative/additional ways to connect using the semantic version. Provide an Admin function to get one version from other. We can also think about re-working "connection type" based on semantic version.
- use the current version number, but the customer/user requires a semantic version use a three digit number, where each digit signifies the major.minor.micro
So, I favor to keep the version as is, and adopt/recommend to alternatives like above.
> Add support for semantic versioning of VDBs
> -------------------------------------------
>
> Key: TEIID-3462
> URL: https://issues.jboss.org/browse/TEIID-3462
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.7
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> Semantic versioning [1] should be supported in the VDB versioning in order to be able to easier determine whether there are breaking changes from the client perspective and to more easily establish a link between client software versions and the VDBs they rely upon.
> [1] http://semver.org/
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (TEIID-3715) MongoDB metadata import fails
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3715?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3715:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1246153|https://bugzilla.redhat.com/show_bug.cgi?id=1246153] from ASSIGNED to MODIFIED
> MongoDB metadata import fails
> -----------------------------
>
> Key: TEIID-3715
> URL: https://issues.jboss.org/browse/TEIID-3715
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.7.1.6_2
> Reporter: Andrej Šmigala
> Assignee: Ramesh Reddy
>
> Deploying the following dynamic vdb fails when Teiid Connection importer is used:
> {code}
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <vdb name="mongo" version="1">
> <description>Importer VDB</description>
> <property name="UseConnectorMetadata" value="true" />
> <property name="deployment-name" value="mongo-vdb.xml" />
> <model name="importVDBSrcModel">
> <source name="importVDBSrcModel" translator-name="mongodb" connection-jndi-name="java:/mongoDS" />
> </model>
> </vdb>
> {code}
> The resource adapter is defined as:
> {code}
> <resource-adapter id="mongoDS">
> <module slot="main" id="org.jboss.teiid.resource-adapter.mongodb"/>
> <transaction-support>NoTransaction</transaction-support>
> <connection-definitions>
> <connection-definition class-name="org.teiid.resource.adapter.mongodb.MongoDBManagedConnectionFactory" jndi-name="java:/mongoDS" enabled="true" use-java-context="true" pool-name="mongoDS">
> <config-property name="Database">
> bqt
> </config-property>
> <config-property name="RemoteServerList">
> vmgdb01.mw.lab.eng.bos.redhat.com:27017
> </config-property>
> <config-property name="Username">
> dv
> </config-property>
> <config-property name="Password">
> dv
> </config-property>
> </connection-definition>
> </connection-definitions>
> </resource-adapter>
> {code}
> Server log:
> {code}
> 08:26:05,590 WARN [org.teiid.RUNTIME] (teiid-async-threads - 4) TEIID50036 VDB mongo.1 model "importVDBSrcModel" metadata failed to load. Reason:not authorized for query on bqt.system.users: com.mongodb.MongoException: not authorized for query on bqt.system.users
> at com.mongodb.MongoException.parse(MongoException.java:82)
> at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:292)
> at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:273)
> at com.mongodb.DBCursor._check(DBCursor.java:368)
> at com.mongodb.DBCursor._hasNext(DBCursor.java:459)
> at com.mongodb.DBCursor.hasNext(DBCursor.java:484)
> at org.teiid.translator.mongodb.MongoDBMetadataProcessor.process(MongoDBMetadataProcessor.java:58)
> at org.teiid.translator.mongodb.MongoDBMetadataProcessor.process(MongoDBMetadataProcessor.java:39)
> at org.teiid.translator.ExecutionFactory.getMetadata(ExecutionFactory.java:935) [teiid-api-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:73) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.jboss.VDBService$6.run(VDBService.java:395) [teiid-jboss-integration-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.jboss.VDBService$7.run(VDBService.java:442) [teiid-jboss-integration-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (TEIID-3589) MongoDB metadata import fails with NPE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3589?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3589:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1246153|https://bugzilla.redhat.com/show_bug.cgi?id=1246153] from ASSIGNED to MODIFIED
> MongoDB metadata import fails with NPE
> --------------------------------------
>
> Key: TEIID-3589
> URL: https://issues.jboss.org/browse/TEIID-3589
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.7.1.6_2
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Labels: Beta1, ER5
> Fix For: 8.7.1.6_2, 8.12
>
>
> Deploying the following dynamic vdb fails with a NullPointerException when Teiid Connection importer is used:
> {code}
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <vdb name="mongo" version="1">
> <description>Importer VDB</description>
> <property name="UseConnectorMetadata" value="true" />
> <property name="deployment-name" value="mongo-vdb.xml" />
> <model name="importVDBSrcModel">
> <source name="importVDBSrcModel" translator-name="mongodb" connection-jndi-name="java:/mongoDS" />
> </model>
> </vdb>
> {code}
> The resource adapter is defined as:
> {code}
> <resource-adapter id="mongoDS">
> <module slot="main" id="org.jboss.teiid.resource-adapter.mongodb"/>
> <transaction-support>NoTransaction</transaction-support>
> <connection-definitions>
> <connection-definition class-name="org.teiid.resource.adapter.mongodb.MongoDBManagedConnectionFactory" jndi-name="java:/mongoDS" enabled="true" use-java-context="true" pool-name="mongoDS">
> <config-property name="Database">
> bqt
> </config-property>
> <config-property name="RemoteServerList">
> vmgdb01.mw.lab.eng.bos.redhat.com:27017
> </config-property>
> <config-property name="Username">
> dv
> </config-property>
> <config-property name="Password">
> dv
> </config-property>
> </connection-definition>
> </connection-definitions>
> </resource-adapter>
> {code}
> Server log:
> {code}
> 16:46:49,793 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "mongo-vdb.xml" (runtime-name: "mongo-vdb.xml")
> 16:46:49,809 DEBUG [org.teiid.RUNTIME] (MSC service thread 1-5) VDB mongo-vdb.xml has been parsed.
> 16:46:49,835 INFO [org.teiid.RUNTIME] (MSC service thread 1-1) TEIID50029 VDB mongo.1 model "importVDBSrcModel" metadata is currently being loaded. Start Time: 7/23/15 4:46 PM
> 16:46:49,869 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015859: Deployed "mongo-vdb.xml" (runtime-name : "mongo-vdb.xml")
> 16:46:50,626 WARN [org.teiid.RUNTIME] (teiid-async-threads - 3) TEIID50036 VDB mongo.1 model "importVDBSrcModel" metadata failed to load. Reason:java.lang.NullPointerException: java.lang.NullPointerException
> at org.teiid.translator.mongodb.MongoDBMetadataProcessor.addTable(MongoDBMetadataProcessor.java:92)
> at org.teiid.translator.mongodb.MongoDBMetadataProcessor.process(MongoDBMetadataProcessor.java:57)
> at org.teiid.translator.mongodb.MongoDBMetadataProcessor.process(MongoDBMetadataProcessor.java:38)
> at org.teiid.translator.ExecutionFactory.getMetadata(ExecutionFactory.java:935) [teiid-api-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:73) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.jboss.VDBService$6.run(VDBService.java:395) [teiid-jboss-integration-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.jboss.VDBService$7.run(VDBService.java:442) [teiid-jboss-integration-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month