[JBoss JIRA] (TEIID-3754) Remove OData V2 implementation of the Server
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3754?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3754:
-------------------------------------
Will leave it alone for now then. We can make remark about deprecation in the blog entry and release notes.
> Remove OData V2 implementation of the Server
> --------------------------------------------
>
> Key: TEIID-3754
> URL: https://issues.jboss.org/browse/TEIID-3754
> Project: Teiid
> Issue Type: Task
> Components: OData
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 9.0
>
>
> We need to remove server implementation of OData V2 specification from Teiid in favor of OData V4.
> The OData V2 translator, we should keep, however that may needs to be updated/re-written using the Olingo. However that is separate issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (TEIID-3684) RoleBasedCredentialMapIdentityLoginModule throws exception at startup time
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3684?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-3684.
---------------------------------
Resolution: Done
Deprecated in 8.12.5, removed in 9.0
Updated the documents accordingly, is there place we are tracking the migration issues?
> RoleBasedCredentialMapIdentityLoginModule throws exception at startup time
> --------------------------------------------------------------------------
>
> Key: TEIID-3684
> URL: https://issues.jboss.org/browse/TEIID-3684
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> If a data source is configured to use RoleBasedCredentialMapIdentityLoginModule, then exception is thrown at startup \[1\], because default username and password are null. Please, add module options "username" and "password" to set up default user (similar functionality have e.g. CallerIdentityLoginModule and PassthroughIdentityLoginModule), so DV is able to properly load data source at startup when no user is authenticated and therefore no mapping could be performed.
> Example configuration \[2\]. Note, there is no exception if UsersRoles login module is used instead of RealDirect. However, it means that EAP users are separate from DV users.
> *FYI:*
> - credentialMap module option should be defined as URL (file://...). It would be nice to have this information in the documentation.
> - I tried to use unauthenticatedIdentity module option for RealmDirect, but same exception has been thrown with different root cause (realm 'ApplicationRealm' not found). I do not know why.
> \[1\]
> ERROR [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-5) Exception during createSubject()PBOX000016: Access denied: authentication failed: java.lang.SecurityException: PBOX000016: Access denied: authentication failed
> at org.jboss.security.plugins.JBossSecuritySubjectFactory.createSubject(JBossSecuritySubjectFactory.java:84)
> at org.jboss.jca.deployers.common.AbstractDsDeployer$1.run(AbstractDsDeployer.java:1084)
> at org.jboss.jca.deployers.common.AbstractDsDeployer$1.run(AbstractDsDeployer.java:1079)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_40]
> at org.jboss.jca.deployers.common.AbstractDsDeployer.createSubject(AbstractDsDeployer.java:1078)
> at org.jboss.jca.deployers.common.AbstractDsDeployer.deployDataSource(AbstractDsDeployer.java:600)
> at org.jboss.jca.deployers.common.AbstractDsDeployer.createObjectsAndInjectValue(AbstractDsDeployer.java:282)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:316)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:120)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40]
> \[2\]
> {code:xml}
> <security-domain name="my-sec">
> <authentication>
> <login-module code="RealmDirect" flag="required">
> <module-option name="password-stacking" value="tryFirstPass"/>
> <!--<module-option name="unauthenticatedIdentity" value="guest"/>-->
> </login-module>
> <login-module code="org.teiid.jboss.RoleBasedCredentialMapIdentityLoginModule" module="org.jboss.teiid" flag="required">
> <module-option name="password-stacking" value="useFirstPass"/>
> <module-option name="credentialMap" value="file://${jboss.server.config.dir}/teiid-credentialmap.properties"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (TEIID-3754) Remove OData V2 implementation of the Server
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3754?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3754:
---------------------------------------
Deprecate yes, but removal should probably wait until 9.1 or later as there's a lot more testing/usage that OData4 will go through in the next couple of months.
> Remove OData V2 implementation of the Server
> --------------------------------------------
>
> Key: TEIID-3754
> URL: https://issues.jboss.org/browse/TEIID-3754
> Project: Teiid
> Issue Type: Task
> Components: OData
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 9.0
>
>
> We need to remove server implementation of OData V2 specification from Teiid in favor of OData V4.
> The OData V2 translator, we should keep, however that may needs to be updated/re-written using the Olingo. However that is separate issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (TEIID-3948) Provide a different mechanism to update odata wars
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3948?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3948:
-------------------------------------
>The cli scripts are already in charge of doing the war deployments and a modification to override the web.xml would be a copy/paste exercise (or just commented out in the cli script file).
yes, this is happening by install scripts, but what we are talking about is by the user. My worry is web.xml is not the only thing that might require change. In the case of the oauth/saml there were certificates to be added, jboss-web.xml and additional keycloak configuration files etc. I do not like to set a different way to handle this simple case and then do the other way for rest of the usecases.
>Can you elaborate on that? Do you mean that it's better to have a self contained artifact?
These changes will not be part of the WAR file, but they will exist in the "deployments" folder some how. Now when one migrates to a different server or newer version then the burden is on us to move these appropriately. What I am saying let the user own the changes, in self contained WAR file, then it is matter of just moving their artifact to a newer server.
>You mean if you rely on embedded and have a separate kitting option for EAP/AS. It still seems heavy weight for users to then do a git checkout, modification, and maven build to just >update properties in the web.xml.
This embedded option as you say is for different purpose than this, that is for us to promote ourselves as drop-in OData provider (in any JEE container) for any datasource. Here, I am just laying out a usecase as to why we would need to move OData project to a separate repo, not for this individual issue.
> Provide a different mechanism to update odata wars
> --------------------------------------------------
>
> Key: TEIID-3948
> URL: https://issues.jboss.org/browse/TEIID-3948
> Project: Teiid
> Issue Type: Quality Risk
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5
>
>
> Directly modifying the wars under the base modules is a bad practice. We need to have users modify non-kit artifact files in a different location.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (TEIID-3973) org.teiid.core.TeiidComponentException: TEIID30328 Unable to evaluate COLUMN1: No value was available
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3973?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3973:
------------------------------------------------
jolee(a)redhat.com changed the Status of [bug 1306854|https://bugzilla.redhat.com/show_bug.cgi?id=1306854] from MODIFIED to ON_QA
> org.teiid.core.TeiidComponentException: TEIID30328 Unable to evaluate COLUMN1: No value was available
> -----------------------------------------------------------------------------------------------------
>
> Key: TEIID-3973
> URL: https://issues.jboss.org/browse/TEIID-3973
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5, 8.13.1, 8.7.3.6_2
>
>
> 2016-02-08 20:58:00,443 ERROR \[org.teiid.PROCESSOR\] (Worker5_QueryProcessorQueue48) TEIID30019 Unexpected exception for request CFlgti3h4soJ.5: org.teiid.core.TeiidComponentException: TEIID30328 Unable to evaluate COLUMN1: No value was available
> at org.teiid.query.util.CommandContext.getFromContext(CommandContext.java:490) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.eval.Evaluator.internalEvaluate(Evaluator.java:639) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:1180) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.eval.Evaluator.internalEvaluate(Evaluator.java:644) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:614) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:283) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.eval.Evaluator.internalEvaluateTVL(Evaluator.java:223) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.eval.Evaluator.evaluateTVL(Evaluator.java:212) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:206) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.SelectNode.nextBatchDirect(SelectNode.java:110) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:69) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:70) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:84) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.common.buffer.AbstractTupleSource.hasNext(AbstractTupleSource.java:92) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.MergeJoinStrategy.process(MergeJoinStrategy.java:149) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:211) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:69) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:70) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:84) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.common.buffer.AbstractTupleSource.nextTuple(AbstractTupleSource.java:48) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.EnhancedSortMergeJoinStrategy.process(EnhancedSortMergeJoinStrategy.java:383) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:211) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:159) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.SourceState.prefetch(SourceState.java:206) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.JoinNode.prefetch(JoinNode.java:231) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:219) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:69) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:70) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:84) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.common.buffer.AbstractTupleSource.nextTuple(AbstractTupleSource.java:48) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.SortUtility.initialSort(SortUtility.java:269) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.SortUtility.sort(SortUtility.java:202) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.SortNode.sortPhase(SortNode.java:112) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.SortNode.nextBatchDirect(SortNode.java:91) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:136) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:159) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:141) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:444) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:326) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:254) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:274) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-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_65]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (TEIID-3950) UDFs aren't found when using old function definitions model
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3950?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3950:
------------------------------------------------
Alex Szczuczko <aszczucz(a)redhat.com> changed the Status of [bug 1304743|https://bugzilla.redhat.com/show_bug.cgi?id=1304743] from MODIFIED to ON_QA
> UDFs aren't found when using old function definitions model
> -----------------------------------------------------------
>
> Key: TEIID-3950
> URL: https://issues.jboss.org/browse/TEIID-3950
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7.2.6_2
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5, 8.13.1, 8.7.3.6_2
>
>
> When migrating an old VDB that contains the old functiondefinitions model the server sees it as a Function model[1] but the functions are not found [2]when you try to use them.
> [1] [org.teiid.RUNTIME] (MSC service thread 1-7) Model udfTokenFunctions in VDB oldUDF skipped being loaded because of its type FUNCTION
> [2] [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue10) org.teiid.api.exception.query.QueryResolverException: TEIID30068 The function 'getToken('125421', '?', 2)' is an unknown form. Check that the function name and number of arguments is correct. Sending error to client 1trCiU5AkzFn.5
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months