[JBoss JIRA] (TEIID-4561) Deprecate the PassthroughIdentityLoginModule
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4561?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4561:
-------------------------------------
In the web tier you I did not have access to the Subject, this this paradigm is used to pass the credential, once it gets to the PassthoughLoginModule it copies into Subject. This worked fine since web tier user single thread execution and same thread makes the LocalConnection into the Teiid.
So, how are you thinking to grab the editable Subject at web layer?
> Deprecate the PassthroughIdentityLoginModule
> --------------------------------------------
>
> Key: TEIID-4561
> URL: https://issues.jboss.org/browse/TEIID-4561
> Project: Teiid
> Issue Type: Quality Risk
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.2
>
>
> The delegation capability of the PassthroughIdentityLoginModule can be associated with the underlying OAuth10/20 login modules (similar to the delegationCredential behavior of the KerberosLoginModule). Also the OAuthCredentialContext should be changed to use the Subject private credentials rather than a ThreadLocal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4567) UCASE and LCASE functions do not work with CLOBs.
by sameer P (JIRA)
sameer P created TEIID-4567:
-------------------------------
Summary: UCASE and LCASE functions do not work with CLOBs.
Key: TEIID-4567
URL: https://issues.jboss.org/browse/TEIID-4567
Project: Teiid
Issue Type: Bug
Components: Common
Affects Versions: 9.1.1
Environment: In any Environment
Reporter: sameer P
Assignee: Steven Hawkins
Priority: Blocker
With the fresh Server, without adding any datasource, if I run the query :
{code:sql}
select lcase(convert('A', clob))
{code} ,
It gives the following exception:
{code:sql}
org.teiid.jdbc.TeiidSQLException: TEIID30328 Remote org.teiid.api.exception.query.ExpressionEvaluationException: TEIID30328 Unable to evaluate lcase(?): TEIID30341 Function lcase is marked in the function metadata as a function that must be evaluated at the source.
at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:135)
at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:71)
at org.teiid.jdbc.StatementImpl.postReceiveResults(StatementImpl.java:723)
at org.teiid.jdbc.StatementImpl.access$100(StatementImpl.java:65)
at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:561)
at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:135)
at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:40)
at org.teiid.client.util.ResultsFuture$1.receiveResults(ResultsFuture.java:79)
at org.teiid.net.socket.SocketServerInstanceImpl.receivedMessage(SocketServerInstanceImpl.java:284)
at org.teiid.net.socket.SocketServerInstanceImpl.read(SocketServerInstanceImpl.java:322)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.teiid.net.socket.SocketServerConnectionFactory$ShutdownHandler.invoke(SocketServerConnectionFactory.java:98)
at com.sun.proxy.$Proxy1.read(Unknown Source)
at org.teiid.net.socket.SocketServerInstanceImpl$RemoteInvocationHandler$1.get(SocketServerInstanceImpl.java:421)
at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:570)
at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:423)
at org.teiid.jdbc.StatementImpl.executeQuery(StatementImpl.java:354)
at DVConnection.main(DVConnection.java:110)
Caused by: org.teiid.core.TeiidProcessingException: TEIID30328 Remote org.teiid.api.exception.query.ExpressionEvaluationException: TEIID30328 Unable to evaluate lcase(?): TEIID30341 Function lcase is marked in the function metadata as a function that must be evaluated at the source.
at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:728)
at org.teiid.query.processor.relational.ProjectNode.updateTuple(ProjectNode.java:194)
at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:169)
at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145)
at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151)
at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:477)
at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:349)
at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:275)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.teiid.core.TeiidProcessingException: TEIID30341 Remote org.teiid.api.exception.query.ExpressionEvaluationException: TEIID30341 Function lcase is marked in the function metadata as a function that must be evaluated at the source.
at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:1389)
at org.teiid.query.eval.Evaluator.internalEvaluate(Evaluator.java:756)
at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:726)
... 18 more
Caused by: org.teiid.core.TeiidProcessingException: TEIID30341 Remote org.teiid.api.exception.query.FunctionExecutionException: TEIID30341 Function lcase is marked in the function metadata as a function that must be evaluated at the source.
at org.teiid.query.processor.relational.SubqueryAwareEvaluator.evaluatePushdown(SubqueryAwareEvaluator.java:438)
at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:1387)
... 20 more
Exception in thread "main" org.teiid.jdbc.TeiidSQLException: TEIID30328 Remote org.teiid.api.exception.query.ExpressionEvaluationException: TEIID30328 Unable to evaluate lcase(?): TEIID30341 Function lcase is marked in the function metadata as a function that must be evaluated at the source.
at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:135)
at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:71)
at org.teiid.jdbc.StatementImpl.postReceiveResults(StatementImpl.java:723)
at org.teiid.jdbc.StatementImpl.access$100(StatementImpl.java:65)
at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:561)
at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:135)
at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:40)
at org.teiid.client.util.ResultsFuture$1.receiveResults(ResultsFuture.java:79)
at org.teiid.net.socket.SocketServerInstanceImpl.receivedMessage(SocketServerInstanceImpl.java:284)
at org.teiid.net.socket.SocketServerInstanceImpl.read(SocketServerInstanceImpl.java:322)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.teiid.net.socket.SocketServerConnectionFactory$ShutdownHandler.invoke(SocketServerConnectionFactory.java:98)
at com.sun.proxy.$Proxy1.read(Unknown Source)
at org.teiid.net.socket.SocketServerInstanceImpl$RemoteInvocationHandler$1.get(SocketServerInstanceImpl.java:421)
at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:570)
at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:423)
at org.teiid.jdbc.StatementImpl.executeQuery(StatementImpl.java:354)
at DVConnection.main(DVConnection.java:110)
Caused by: org.teiid.core.TeiidProcessingException: TEIID30328 Remote org.teiid.api.exception.query.ExpressionEvaluationException: TEIID30328 Unable to evaluate lcase(?): TEIID30341 Function lcase is marked in the function metadata as a function that must be evaluated at the source.
at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:728)
at org.teiid.query.processor.relational.ProjectNode.updateTuple(ProjectNode.java:194)
at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:169)
at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145)
at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151)
at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:477)
at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:349)
at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:275)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.teiid.core.TeiidProcessingException: TEIID30341 Remote org.teiid.api.exception.query.ExpressionEvaluationException: TEIID30341 Function lcase is marked in the function metadata as a function that must be evaluated at the source.
at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:1389)
at org.teiid.query.eval.Evaluator.internalEvaluate(Evaluator.java:756)
at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:726)
... 18 more
Caused by: org.teiid.core.TeiidProcessingException: TEIID30341 Remote org.teiid.api.exception.query.FunctionExecutionException: TEIID30341 Function lcase is marked in the function metadata as a function that must be evaluated at the source.
at org.teiid.query.processor.relational.SubqueryAwareEvaluator.evaluatePushdown(SubqueryAwareEvaluator.java:438)
at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:1387)
... 20 more
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4437) Convert Teiid build to use "feature-pack"
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4437?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-4437:
------------------------------------
> There are also some failures when running the arquillian tests, which we'll need to address as well.
Do you think these failed due to feature pack change?
> Convert Teiid build to use "feature-pack"
> -----------------------------------------
>
> Key: TEIID-4437
> URL: https://issues.jboss.org/browse/TEIID-4437
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.2
>
>
> Change the current build process to build "feature-packs" for project, and then based on feature pack, build
> - WildFly Server distribution
> -WildFly Server Overlay distribution
> Teiid currently have distributions, but not based on feature-packs, they need to be. Other distributions like AdminShell do not fall into this category. Only distributions that has WF involvement need a feature -pack (this is important to remember).
> Currently Teiid uses "kit" directory in many different projects along with "wildfly-dist.xml" to populate "modules" directory. A feature-pack does EXACTLY same thing, but more with checks and balances. A feature pack, makes sure all the dependencies are met based on module.xml and module.xml defines the maven artifact rather than JAR file. i.e. it defines a metadata file, from which it can be build the zip file that "wildfly-dist.xml" assembly is currently doing. It also can has capabilities to "configure" the WF subsystem. That is manually done or done through CLI currently, using this part will be new.
> Implementation Rules
> 1) Every where we have "kit" directory, that module REQUIRES a "feature-pack" module. That means, every translator and resource-adapter gets it's own, and Teiid engine modules separately gets its own module. The reason to keep/create multiple modules is STRICTLY to keep the "modules" directory in feature-pack aligned ONE TO ONE with project that feature-pack represents. Otherwise, as developer we will NOT know which project is bringing in certain dependency, if all the modules are in single place. So, this is more about management of dependencies in a sane way. (Teiid did have all the modules in once place before in 7.x/8.x time, it is a nightmare to handle growing dependencies with our translators)
> 2) NONE of the work we have is useless/or need to be redone, most everything we have PERFECTLY maps to this effort, except for for configuration part.
> 3) For translator and resource adapter pair, I recommend that we pull them into single sub folder, and create a single feature pack for it. For example:
> we have
> {code}
> connectors/translator-mongodb
> connectors/connector-mongodb
> {code}
> I would like see we design as
> {code}
> connectors
> /mongdb
> /translator-mongodb
> /connector-mongodb
> /feature-pack-mongodb
> {code}
> No need to create "dist" packages for any resource-adapters or translators. As I mentioned in the beginning of the issue, there are two distributions, they are built using these various feature-packs.
> 4) I would like to see a clean move of "kit/wildfly/modules" to "feature-packs" using "git", NOT CUT n PASTE where we loose the GIT history. This will preserve the confidence that what we have currently is EXACTLY same as in future with feature-packs.
> 5) When designing the "feature-pack" projects, they ABSOLUTELY MUST NOT define any dependencies in their pom.xml other than Teiid project(s) they represent and any other feature-pack they refer to. (Kylin this is what cause most concern from your design for me)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4437) Convert Teiid build to use "feature-pack"
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4437?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-4437 at 11/9/16 1:22 AM:
-------------------------------------------------------------
Arquillian tests results:
{code}
Results :
Failed tests:
IntegrationTestDeployment.testGetRequests:372 expected:<0> but was:<1>
IntegrationTestDeployment.testTraslators:195 [jpa2, prestodb, mysql5, swagger, salesforce, metamatrix, ingres, ldap, sap-gateway, derby, mysql, ingres93, salesforce-34, jdbc-simple, loopback, teiid, oracle, sybase, odata4, impala, ucanaccess, cassandra, hive, simpledb, access, vertica, map-cache, google-spreadsheet, h2, modeshape, osisoft-pi, jdbc-ansi, accumulo, odata, file, postgresql, sqlserver, redshift, hsql, greenplum, solr, hana, ws, mongodb, hbase, sybaseiq, netezza, teradata, sap-nw-gateway, informix, excel, intersystems-cache, db2, actian-vector, olap] expected:<56> but was:<55>
IntegrationTestRestWebserviceGeneration.testSemanticVersion:260 sample_2.1.1.war not found
Tests in error:
IntegrationTestDeployment.testGeometry:754 » TeiidSQL TEIID30328 Unable to eva...
Tests run: 42, Failures: 3, Errors: 1, Skipped: 4
{code}
h2. IntegrationTestDeployment.testTraslators()
For the feature pack merge, the below line be removed
{code}
<translator name="delegator" module="org.jboss.teiid.api"/>
{code}
Do we need keep this? if no we need update the arquillian test
h2. IntegrationTestRestWebserviceGeneration.testSemanticVersion
Seems this issue exist in previous version, [~rareddy] can you confirm this, I remembered we have talked this in somewhere
was (Author: kylin):
Arquillian tests results:
{code}
Results :
Failed tests:
IntegrationTestDeployment.testGetRequests:372 expected:<0> but was:<1>
IntegrationTestDeployment.testTraslators:195 [jpa2, prestodb, mysql5, swagger, salesforce, metamatrix, ingres, ldap, sap-gateway, derby, mysql, ingres93, salesforce-34, jdbc-simple, loopback, teiid, oracle, sybase, odata4, impala, ucanaccess, cassandra, hive, simpledb, access, vertica, map-cache, google-spreadsheet, h2, modeshape, osisoft-pi, jdbc-ansi, accumulo, odata, file, postgresql, sqlserver, redshift, hsql, greenplum, solr, hana, ws, mongodb, hbase, sybaseiq, netezza, teradata, sap-nw-gateway, informix, excel, intersystems-cache, db2, actian-vector, olap] expected:<56> but was:<55>
IntegrationTestRestWebserviceGeneration.testSemanticVersion:260 sample_2.1.1.war not found
Tests in error:
IntegrationTestDeployment.testGeometry:754 » TeiidSQL TEIID30328 Unable to eva...
Tests run: 42, Failures: 3, Errors: 1, Skipped: 4
{code}
h2. IntegrationTestDeployment.testTraslators()
For the feature pack merge, the below line be removed
{code}
<translator name="delegator" module="org.jboss.teiid.api"/>
{code}
Do we need keep this? if no we need update the arquillian test
> Convert Teiid build to use "feature-pack"
> -----------------------------------------
>
> Key: TEIID-4437
> URL: https://issues.jboss.org/browse/TEIID-4437
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.2
>
>
> Change the current build process to build "feature-packs" for project, and then based on feature pack, build
> - WildFly Server distribution
> -WildFly Server Overlay distribution
> Teiid currently have distributions, but not based on feature-packs, they need to be. Other distributions like AdminShell do not fall into this category. Only distributions that has WF involvement need a feature -pack (this is important to remember).
> Currently Teiid uses "kit" directory in many different projects along with "wildfly-dist.xml" to populate "modules" directory. A feature-pack does EXACTLY same thing, but more with checks and balances. A feature pack, makes sure all the dependencies are met based on module.xml and module.xml defines the maven artifact rather than JAR file. i.e. it defines a metadata file, from which it can be build the zip file that "wildfly-dist.xml" assembly is currently doing. It also can has capabilities to "configure" the WF subsystem. That is manually done or done through CLI currently, using this part will be new.
> Implementation Rules
> 1) Every where we have "kit" directory, that module REQUIRES a "feature-pack" module. That means, every translator and resource-adapter gets it's own, and Teiid engine modules separately gets its own module. The reason to keep/create multiple modules is STRICTLY to keep the "modules" directory in feature-pack aligned ONE TO ONE with project that feature-pack represents. Otherwise, as developer we will NOT know which project is bringing in certain dependency, if all the modules are in single place. So, this is more about management of dependencies in a sane way. (Teiid did have all the modules in once place before in 7.x/8.x time, it is a nightmare to handle growing dependencies with our translators)
> 2) NONE of the work we have is useless/or need to be redone, most everything we have PERFECTLY maps to this effort, except for for configuration part.
> 3) For translator and resource adapter pair, I recommend that we pull them into single sub folder, and create a single feature pack for it. For example:
> we have
> {code}
> connectors/translator-mongodb
> connectors/connector-mongodb
> {code}
> I would like see we design as
> {code}
> connectors
> /mongdb
> /translator-mongodb
> /connector-mongodb
> /feature-pack-mongodb
> {code}
> No need to create "dist" packages for any resource-adapters or translators. As I mentioned in the beginning of the issue, there are two distributions, they are built using these various feature-packs.
> 4) I would like to see a clean move of "kit/wildfly/modules" to "feature-packs" using "git", NOT CUT n PASTE where we loose the GIT history. This will preserve the confidence that what we have currently is EXACTLY same as in future with feature-packs.
> 5) When designing the "feature-pack" projects, they ABSOLUTELY MUST NOT define any dependencies in their pom.xml other than Teiid project(s) they represent and any other feature-pack they refer to. (Kylin this is what cause most concern from your design for me)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4437) Convert Teiid build to use "feature-pack"
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4437?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-4437 at 11/9/16 1:03 AM:
-------------------------------------------------------------
Arquillian tests results:
{code}
Results :
Failed tests:
IntegrationTestDeployment.testGetRequests:372 expected:<0> but was:<1>
IntegrationTestDeployment.testTraslators:195 [jpa2, prestodb, mysql5, swagger, salesforce, metamatrix, ingres, ldap, sap-gateway, derby, mysql, ingres93, salesforce-34, jdbc-simple, loopback, teiid, oracle, sybase, odata4, impala, ucanaccess, cassandra, hive, simpledb, access, vertica, map-cache, google-spreadsheet, h2, modeshape, osisoft-pi, jdbc-ansi, accumulo, odata, file, postgresql, sqlserver, redshift, hsql, greenplum, solr, hana, ws, mongodb, hbase, sybaseiq, netezza, teradata, sap-nw-gateway, informix, excel, intersystems-cache, db2, actian-vector, olap] expected:<56> but was:<55>
IntegrationTestRestWebserviceGeneration.testSemanticVersion:260 sample_2.1.1.war not found
Tests in error:
IntegrationTestDeployment.testGeometry:754 » TeiidSQL TEIID30328 Unable to eva...
Tests run: 42, Failures: 3, Errors: 1, Skipped: 4
{code}
For the feature pack merge, the below line be removed
{code}
<translator name="delegator" module="org.jboss.teiid.api"/>
{code}
Do we need keep this? if no we need update the arquillian test
was (Author: kylin):
Arquillian tests results:
{code}
Results :
Failed tests:
IntegrationTestDeployment.testGetRequests:372 expected:<0> but was:<1>
IntegrationTestDeployment.testTraslators:195 [jpa2, prestodb, mysql5, swagger, salesforce, metamatrix, ingres, ldap, sap-gateway, derby, mysql, ingres93, salesforce-34, jdbc-simple, loopback, teiid, oracle, sybase, odata4, impala, ucanaccess, cassandra, hive, simpledb, access, vertica, map-cache, google-spreadsheet, h2, modeshape, osisoft-pi, jdbc-ansi, accumulo, odata, file, postgresql, sqlserver, redshift, hsql, greenplum, solr, hana, ws, mongodb, hbase, sybaseiq, netezza, teradata, sap-nw-gateway, informix, excel, intersystems-cache, db2, actian-vector, olap] expected:<56> but was:<55>
IntegrationTestRestWebserviceGeneration.testSemanticVersion:260 sample_2.1.1.war not found
Tests in error:
IntegrationTestDeployment.testGeometry:754 » TeiidSQL TEIID30328 Unable to eva...
Tests run: 42, Failures: 3, Errors: 1, Skipped: 4
{code}
> Convert Teiid build to use "feature-pack"
> -----------------------------------------
>
> Key: TEIID-4437
> URL: https://issues.jboss.org/browse/TEIID-4437
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.2
>
>
> Change the current build process to build "feature-packs" for project, and then based on feature pack, build
> - WildFly Server distribution
> -WildFly Server Overlay distribution
> Teiid currently have distributions, but not based on feature-packs, they need to be. Other distributions like AdminShell do not fall into this category. Only distributions that has WF involvement need a feature -pack (this is important to remember).
> Currently Teiid uses "kit" directory in many different projects along with "wildfly-dist.xml" to populate "modules" directory. A feature-pack does EXACTLY same thing, but more with checks and balances. A feature pack, makes sure all the dependencies are met based on module.xml and module.xml defines the maven artifact rather than JAR file. i.e. it defines a metadata file, from which it can be build the zip file that "wildfly-dist.xml" assembly is currently doing. It also can has capabilities to "configure" the WF subsystem. That is manually done or done through CLI currently, using this part will be new.
> Implementation Rules
> 1) Every where we have "kit" directory, that module REQUIRES a "feature-pack" module. That means, every translator and resource-adapter gets it's own, and Teiid engine modules separately gets its own module. The reason to keep/create multiple modules is STRICTLY to keep the "modules" directory in feature-pack aligned ONE TO ONE with project that feature-pack represents. Otherwise, as developer we will NOT know which project is bringing in certain dependency, if all the modules are in single place. So, this is more about management of dependencies in a sane way. (Teiid did have all the modules in once place before in 7.x/8.x time, it is a nightmare to handle growing dependencies with our translators)
> 2) NONE of the work we have is useless/or need to be redone, most everything we have PERFECTLY maps to this effort, except for for configuration part.
> 3) For translator and resource adapter pair, I recommend that we pull them into single sub folder, and create a single feature pack for it. For example:
> we have
> {code}
> connectors/translator-mongodb
> connectors/connector-mongodb
> {code}
> I would like see we design as
> {code}
> connectors
> /mongdb
> /translator-mongodb
> /connector-mongodb
> /feature-pack-mongodb
> {code}
> No need to create "dist" packages for any resource-adapters or translators. As I mentioned in the beginning of the issue, there are two distributions, they are built using these various feature-packs.
> 4) I would like to see a clean move of "kit/wildfly/modules" to "feature-packs" using "git", NOT CUT n PASTE where we loose the GIT history. This will preserve the confidence that what we have currently is EXACTLY same as in future with feature-packs.
> 5) When designing the "feature-pack" projects, they ABSOLUTELY MUST NOT define any dependencies in their pom.xml other than Teiid project(s) they represent and any other feature-pack they refer to. (Kylin this is what cause most concern from your design for me)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4437) Convert Teiid build to use "feature-pack"
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4437?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-4437 at 11/9/16 1:03 AM:
-------------------------------------------------------------
Arquillian tests results:
{code}
Results :
Failed tests:
IntegrationTestDeployment.testGetRequests:372 expected:<0> but was:<1>
IntegrationTestDeployment.testTraslators:195 [jpa2, prestodb, mysql5, swagger, salesforce, metamatrix, ingres, ldap, sap-gateway, derby, mysql, ingres93, salesforce-34, jdbc-simple, loopback, teiid, oracle, sybase, odata4, impala, ucanaccess, cassandra, hive, simpledb, access, vertica, map-cache, google-spreadsheet, h2, modeshape, osisoft-pi, jdbc-ansi, accumulo, odata, file, postgresql, sqlserver, redshift, hsql, greenplum, solr, hana, ws, mongodb, hbase, sybaseiq, netezza, teradata, sap-nw-gateway, informix, excel, intersystems-cache, db2, actian-vector, olap] expected:<56> but was:<55>
IntegrationTestRestWebserviceGeneration.testSemanticVersion:260 sample_2.1.1.war not found
Tests in error:
IntegrationTestDeployment.testGeometry:754 » TeiidSQL TEIID30328 Unable to eva...
Tests run: 42, Failures: 3, Errors: 1, Skipped: 4
{code}
h2. IntegrationTestDeployment.testTraslators()
For the feature pack merge, the below line be removed
{code}
<translator name="delegator" module="org.jboss.teiid.api"/>
{code}
Do we need keep this? if no we need update the arquillian test
was (Author: kylin):
Arquillian tests results:
{code}
Results :
Failed tests:
IntegrationTestDeployment.testGetRequests:372 expected:<0> but was:<1>
IntegrationTestDeployment.testTraslators:195 [jpa2, prestodb, mysql5, swagger, salesforce, metamatrix, ingres, ldap, sap-gateway, derby, mysql, ingres93, salesforce-34, jdbc-simple, loopback, teiid, oracle, sybase, odata4, impala, ucanaccess, cassandra, hive, simpledb, access, vertica, map-cache, google-spreadsheet, h2, modeshape, osisoft-pi, jdbc-ansi, accumulo, odata, file, postgresql, sqlserver, redshift, hsql, greenplum, solr, hana, ws, mongodb, hbase, sybaseiq, netezza, teradata, sap-nw-gateway, informix, excel, intersystems-cache, db2, actian-vector, olap] expected:<56> but was:<55>
IntegrationTestRestWebserviceGeneration.testSemanticVersion:260 sample_2.1.1.war not found
Tests in error:
IntegrationTestDeployment.testGeometry:754 » TeiidSQL TEIID30328 Unable to eva...
Tests run: 42, Failures: 3, Errors: 1, Skipped: 4
{code}
For the feature pack merge, the below line be removed
{code}
<translator name="delegator" module="org.jboss.teiid.api"/>
{code}
Do we need keep this? if no we need update the arquillian test
> Convert Teiid build to use "feature-pack"
> -----------------------------------------
>
> Key: TEIID-4437
> URL: https://issues.jboss.org/browse/TEIID-4437
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.2
>
>
> Change the current build process to build "feature-packs" for project, and then based on feature pack, build
> - WildFly Server distribution
> -WildFly Server Overlay distribution
> Teiid currently have distributions, but not based on feature-packs, they need to be. Other distributions like AdminShell do not fall into this category. Only distributions that has WF involvement need a feature -pack (this is important to remember).
> Currently Teiid uses "kit" directory in many different projects along with "wildfly-dist.xml" to populate "modules" directory. A feature-pack does EXACTLY same thing, but more with checks and balances. A feature pack, makes sure all the dependencies are met based on module.xml and module.xml defines the maven artifact rather than JAR file. i.e. it defines a metadata file, from which it can be build the zip file that "wildfly-dist.xml" assembly is currently doing. It also can has capabilities to "configure" the WF subsystem. That is manually done or done through CLI currently, using this part will be new.
> Implementation Rules
> 1) Every where we have "kit" directory, that module REQUIRES a "feature-pack" module. That means, every translator and resource-adapter gets it's own, and Teiid engine modules separately gets its own module. The reason to keep/create multiple modules is STRICTLY to keep the "modules" directory in feature-pack aligned ONE TO ONE with project that feature-pack represents. Otherwise, as developer we will NOT know which project is bringing in certain dependency, if all the modules are in single place. So, this is more about management of dependencies in a sane way. (Teiid did have all the modules in once place before in 7.x/8.x time, it is a nightmare to handle growing dependencies with our translators)
> 2) NONE of the work we have is useless/or need to be redone, most everything we have PERFECTLY maps to this effort, except for for configuration part.
> 3) For translator and resource adapter pair, I recommend that we pull them into single sub folder, and create a single feature pack for it. For example:
> we have
> {code}
> connectors/translator-mongodb
> connectors/connector-mongodb
> {code}
> I would like see we design as
> {code}
> connectors
> /mongdb
> /translator-mongodb
> /connector-mongodb
> /feature-pack-mongodb
> {code}
> No need to create "dist" packages for any resource-adapters or translators. As I mentioned in the beginning of the issue, there are two distributions, they are built using these various feature-packs.
> 4) I would like to see a clean move of "kit/wildfly/modules" to "feature-packs" using "git", NOT CUT n PASTE where we loose the GIT history. This will preserve the confidence that what we have currently is EXACTLY same as in future with feature-packs.
> 5) When designing the "feature-pack" projects, they ABSOLUTELY MUST NOT define any dependencies in their pom.xml other than Teiid project(s) they represent and any other feature-pack they refer to. (Kylin this is what cause most concern from your design for me)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4561) Deprecate the PassthroughIdentityLoginModule
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4561?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4561:
-------------------------------------
Where is OAuthCrentialContext using the ThreadLocal? It is always used private credentials.
> Deprecate the PassthroughIdentityLoginModule
> --------------------------------------------
>
> Key: TEIID-4561
> URL: https://issues.jboss.org/browse/TEIID-4561
> Project: Teiid
> Issue Type: Quality Risk
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.2
>
>
> The delegation capability of the PassthroughIdentityLoginModule can be associated with the underlying OAuth10/20 login modules (similar to the delegationCredential behavior of the KerberosLoginModule). Also the OAuthCredentialContext should be changed to use the Subject private credentials rather than a ThreadLocal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4437) Convert Teiid build to use "feature-pack"
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4437?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-4437:
------------------------------------
Arquillian tests results:
{code}
Results :
Failed tests:
IntegrationTestDeployment.testGetRequests:372 expected:<0> but was:<1>
IntegrationTestDeployment.testTraslators:195 [jpa2, prestodb, mysql5, swagger, salesforce, metamatrix, ingres, ldap, sap-gateway, derby, mysql, ingres93, salesforce-34, jdbc-simple, loopback, teiid, oracle, sybase, odata4, impala, ucanaccess, cassandra, hive, simpledb, access, vertica, map-cache, google-spreadsheet, h2, modeshape, osisoft-pi, jdbc-ansi, accumulo, odata, file, postgresql, sqlserver, redshift, hsql, greenplum, solr, hana, ws, mongodb, hbase, sybaseiq, netezza, teradata, sap-nw-gateway, informix, excel, intersystems-cache, db2, actian-vector, olap] expected:<56> but was:<55>
IntegrationTestRestWebserviceGeneration.testSemanticVersion:260 sample_2.1.1.war not found
Tests in error:
IntegrationTestDeployment.testGeometry:754 » TeiidSQL TEIID30328 Unable to eva...
Tests run: 42, Failures: 3, Errors: 1, Skipped: 4
{code}
> Convert Teiid build to use "feature-pack"
> -----------------------------------------
>
> Key: TEIID-4437
> URL: https://issues.jboss.org/browse/TEIID-4437
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.2
>
>
> Change the current build process to build "feature-packs" for project, and then based on feature pack, build
> - WildFly Server distribution
> -WildFly Server Overlay distribution
> Teiid currently have distributions, but not based on feature-packs, they need to be. Other distributions like AdminShell do not fall into this category. Only distributions that has WF involvement need a feature -pack (this is important to remember).
> Currently Teiid uses "kit" directory in many different projects along with "wildfly-dist.xml" to populate "modules" directory. A feature-pack does EXACTLY same thing, but more with checks and balances. A feature pack, makes sure all the dependencies are met based on module.xml and module.xml defines the maven artifact rather than JAR file. i.e. it defines a metadata file, from which it can be build the zip file that "wildfly-dist.xml" assembly is currently doing. It also can has capabilities to "configure" the WF subsystem. That is manually done or done through CLI currently, using this part will be new.
> Implementation Rules
> 1) Every where we have "kit" directory, that module REQUIRES a "feature-pack" module. That means, every translator and resource-adapter gets it's own, and Teiid engine modules separately gets its own module. The reason to keep/create multiple modules is STRICTLY to keep the "modules" directory in feature-pack aligned ONE TO ONE with project that feature-pack represents. Otherwise, as developer we will NOT know which project is bringing in certain dependency, if all the modules are in single place. So, this is more about management of dependencies in a sane way. (Teiid did have all the modules in once place before in 7.x/8.x time, it is a nightmare to handle growing dependencies with our translators)
> 2) NONE of the work we have is useless/or need to be redone, most everything we have PERFECTLY maps to this effort, except for for configuration part.
> 3) For translator and resource adapter pair, I recommend that we pull them into single sub folder, and create a single feature pack for it. For example:
> we have
> {code}
> connectors/translator-mongodb
> connectors/connector-mongodb
> {code}
> I would like see we design as
> {code}
> connectors
> /mongdb
> /translator-mongodb
> /connector-mongodb
> /feature-pack-mongodb
> {code}
> No need to create "dist" packages for any resource-adapters or translators. As I mentioned in the beginning of the issue, there are two distributions, they are built using these various feature-packs.
> 4) I would like to see a clean move of "kit/wildfly/modules" to "feature-packs" using "git", NOT CUT n PASTE where we loose the GIT history. This will preserve the confidence that what we have currently is EXACTLY same as in future with feature-packs.
> 5) When designing the "feature-pack" projects, they ABSOLUTELY MUST NOT define any dependencies in their pom.xml other than Teiid project(s) they represent and any other feature-pack they refer to. (Kylin this is what cause most concern from your design for me)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4437) Convert Teiid build to use "feature-pack"
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4437?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4437:
-------------------------------------
{code}
cd test-integrations/common
mvn clean test -P arquillian-tests
{code}
> Convert Teiid build to use "feature-pack"
> -----------------------------------------
>
> Key: TEIID-4437
> URL: https://issues.jboss.org/browse/TEIID-4437
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.2
>
>
> Change the current build process to build "feature-packs" for project, and then based on feature pack, build
> - WildFly Server distribution
> -WildFly Server Overlay distribution
> Teiid currently have distributions, but not based on feature-packs, they need to be. Other distributions like AdminShell do not fall into this category. Only distributions that has WF involvement need a feature -pack (this is important to remember).
> Currently Teiid uses "kit" directory in many different projects along with "wildfly-dist.xml" to populate "modules" directory. A feature-pack does EXACTLY same thing, but more with checks and balances. A feature pack, makes sure all the dependencies are met based on module.xml and module.xml defines the maven artifact rather than JAR file. i.e. it defines a metadata file, from which it can be build the zip file that "wildfly-dist.xml" assembly is currently doing. It also can has capabilities to "configure" the WF subsystem. That is manually done or done through CLI currently, using this part will be new.
> Implementation Rules
> 1) Every where we have "kit" directory, that module REQUIRES a "feature-pack" module. That means, every translator and resource-adapter gets it's own, and Teiid engine modules separately gets its own module. The reason to keep/create multiple modules is STRICTLY to keep the "modules" directory in feature-pack aligned ONE TO ONE with project that feature-pack represents. Otherwise, as developer we will NOT know which project is bringing in certain dependency, if all the modules are in single place. So, this is more about management of dependencies in a sane way. (Teiid did have all the modules in once place before in 7.x/8.x time, it is a nightmare to handle growing dependencies with our translators)
> 2) NONE of the work we have is useless/or need to be redone, most everything we have PERFECTLY maps to this effort, except for for configuration part.
> 3) For translator and resource adapter pair, I recommend that we pull them into single sub folder, and create a single feature pack for it. For example:
> we have
> {code}
> connectors/translator-mongodb
> connectors/connector-mongodb
> {code}
> I would like see we design as
> {code}
> connectors
> /mongdb
> /translator-mongodb
> /connector-mongodb
> /feature-pack-mongodb
> {code}
> No need to create "dist" packages for any resource-adapters or translators. As I mentioned in the beginning of the issue, there are two distributions, they are built using these various feature-packs.
> 4) I would like to see a clean move of "kit/wildfly/modules" to "feature-packs" using "git", NOT CUT n PASTE where we loose the GIT history. This will preserve the confidence that what we have currently is EXACTLY same as in future with feature-packs.
> 5) When designing the "feature-pack" projects, they ABSOLUTELY MUST NOT define any dependencies in their pom.xml other than Teiid project(s) they represent and any other feature-pack they refer to. (Kylin this is what cause most concern from your design for me)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months