[JBoss JIRA] (TEIID-4808) Infinispan Cache Resource Adapter: NullPointerException
by Jan Stastny (JIRA)
Jan Stastny created TEIID-4808:
----------------------------------
Summary: Infinispan Cache Resource Adapter: NullPointerException
Key: TEIID-4808
URL: https://issues.jboss.org/browse/TEIID-4808
Project: Teiid
Issue Type: Bug
Components: JDG Connector
Affects Versions: 8.12.10.6_3
Reporter: Jan Stastny
Assignee: Van Halbert
There is a NPE when trying to query a local cache via Infinispan Cache translator.
{code}
[31m10:27:43,186 ERROR [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue1) Connector worker process failed for atomic-request=6chGAXrxul8Z.0.3.0: java.lang.NullPointerException
at org.teiid.resource.adapter.infinispan.InfinispanCacheWrapper.getClassRegistry(InfinispanCacheWrapper.java:128)
at org.teiid.resource.adapter.infinispan.InfinispanCacheRAConnection.getClassRegistry(InfinispanCacheRAConnection.java:137)
at org.teiid.translator.object.ObjectExecution.<init>(ObjectExecution.java:195) [translator-object-8.12.10.6_3-redhat-1.jar:8.12.10.6_3-redhat-1]
at org.teiid.translator.infinispan.cache.InfinispanCacheExecutionFactory$1.<init>(InfinispanCacheExecutionFactory.java:93) [translator-infinispan-cache-8.12.10.6_3-redhat-1.jar:8.12.10.6_3-redhat-1]
at org.teiid.translator.infinispan.cache.InfinispanCacheExecutionFactory.createResultSetExecution(InfinispanCacheExecutionFactory.java:93) [translator-infinispan-cache-8.12.10.6_3-redhat-1.jar:8.12.10.6_3-redhat-1]
at org.teiid.translator.infinispan.cache.InfinispanCacheExecutionFactory.createResultSetExecution(InfinispanCacheExecutionFactory.java:51) [translator-infinispan-cache-8.12.10.6_3-redhat-1.jar:8.12.10.6_3-redhat-1]
at org.teiid.translator.ExecutionFactory.createExecution(ExecutionFactory.java:316) [teiid-api-8.12.10.6_3-redhat-1.jar:8.12.10.6_3-redhat-1]
at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:354) [teiid-engine-8.12.10.6_3-redhat-1.jar:8.12.10.6_3-redhat-1]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_111]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_111]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_111]
at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_111]
at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211) [teiid-engine-8.12.10.6_3-redhat-1.jar:8.12.10.6_3-redhat-1]
at com.sun.proxy.$Proxy103.execute(Unknown Source)
at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306) [teiid-engine-8.12.10.6_3-redhat-1.jar:8.12.10.6_3-redhat-1]
at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112) [teiid-engine-8.12.10.6_3-redhat-1.jar:8.12.10.6_3-redhat-1]
at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108) [teiid-engine-8.12.10.6_3-redhat-1.jar:8.12.10.6_3-redhat-1]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_111]
at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65) [teiid-engine-8.12.10.6_3-redhat-1.jar:8.12.10.6_3-redhat-1]
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:280) [teiid-engine-8.12.10.6_3-redhat-1.jar:8.12.10.6_3-redhat-1]
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.12.10.6_3-redhat-1.jar:8.12.10.6_3-redhat-1]
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.12.10.6_3-redhat-1.jar:8.12.10.6_3-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_111]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_111]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_111]
{code}
POJO's module.xml:
{code:xml}
<module xmlns="urn:jboss:module:1.1" name="org.jboss.qe.jdg.pojos">
<resources>
<resource-root path="jdg-pojos-1.2.jar"/>
<!-- Insert resources here -->
</resources>
<dependencies>
<!-- local -->
<module name="org.jboss.teiid.resource-adapter.infinispan" slot="6" />
<!--remote-->
<module name="org.infinispan.client.hotrod" slot="jdg-6.4" optional="true" export="true" />
<module name="org.infinispan.protostream" slot="jdg-6.4" optional="true" export="true" />
<module name="org.infinispan.client.hotrod" slot="jdg-6.5" optional="true" export="true" />
<module name="org.infinispan.protostream" slot="jdg-6.5" optional="true" export="true" />
<module name="org.infinispan.client.hotrod" slot="jdg-6.6" optional="true" export="true" />
<module name="org.infinispan.protostream" slot="jdg-6.6" optional="true" export="true" />
</dependencies>
</module>
{code}
Resource-adapter configuration:
{code:xml}
<resource-adapter id="jdg-ra-ds">
<module slot="6" id="org.jboss.teiid.resource-adapter.infinispan"/>
<transaction-support>LocalTransaction</transaction-support>
<connection-definitions>
<connection-definition class-name="org.teiid.resource.adapter.infinispan.InfinispanManagedConnectionFactory" jndi-name="java:/infinispanTest" enabled="true" use-java-context="true" pool-name="jdg-ra-ds">
<config-property name="CacheJndiName">
java:jboss/infinispan/container/teiid-infinispan-quickstart
</config-property>
<config-property name="Module">
org.jboss.qe.jdg.pojos
</config-property>
<config-property name="CacheTypeMap">
local-quickstart-cache:org.jboss.qe.jdg.pojo.SmallA;intKey
</config-property>
</connection-definition>
</connection-definitions>
</resource-adapter>
{code}
Translator:
{code:xml}
<translator name="infinispan-cache" module="org.jboss.teiid.translator.infinispan.cache"/>
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4575) No such accessible property/method in the class after deploy vdb
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4575?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4575:
----------------------------------
Fix Version/s: 9.2.2
9.3
(was: 9.2.1)
> No such accessible property/method in the class after deploy vdb
> ----------------------------------------------------------------
>
> Key: TEIID-4575
> URL: https://issues.jboss.org/browse/TEIID-4575
> Project: Teiid
> Issue Type: Bug
> Components: Documentation, JDG Connector
> Affects Versions: 9.2
> Reporter: Matej Kralik
> Assignee: Van Halbert
> Fix For: 9.3, 9.2.2
>
> Attachments: JDGproject.zip
>
>
> When I want to deploy dynamic VDB with JDG materialization, the server shows me : TEIID31111 No such accessible property/method ISBN on class org.teiid.jdg.pojo.Book.
> I looked at Book.java and ISBN is there.
> The class is generated in the teiid designer. In the attachment is the project with dynamicVDB and generated JDG module.
> Stacktrace:
> {code:java}
> 12:34:07,140 WARN [org.teiid.CONNECTOR] (Worker0_QueryProcessorQueue223) Connector worker process failed for atomic-request=e3xcwoJghvNm.0.69.131: org.teiid.translator.TranslatorException: TEIID31111 No such accessible property/method ISBN on class org.teiid.jdg.pojo.Book.
> at org.teiid.translator.object.ObjectUpdateExecution.evaluate(ObjectUpdateExecution.java:524) [translator-object-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.translator.object.ObjectUpdateExecution.handleInsert(ObjectUpdateExecution.java:219) [translator-object-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.translator.object.ObjectUpdateExecution.executeUpdate(ObjectUpdateExecution.java:150) [translator-object-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.translator.object.ObjectUpdateExecution.execute(ObjectUpdateExecution.java:108) [translator-object-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem$1.execute(ConnectorWorkItem.java:402) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:364) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at sun.reflect.GeneratedMethodAccessor169.invoke(Unknown Source) [:1.8.0_91]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_91]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_91]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at com.sun.proxy.$Proxy46.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.DataTierTupleSource.nextTuple(DataTierTupleSource.java:142) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.relational.ProjectIntoNode.checkExitConditions(ProjectIntoNode.java:264) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.relational.ProjectIntoNode.nextBatchDirect(ProjectIntoNode.java:164) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:69) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:70) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:84) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.common.buffer.AbstractTupleSource.hasNext(AbstractTupleSource.java:92) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.proc.ProcedurePlan.executePlan(ProcedurePlan.java:608) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.proc.CreateCursorResultSetInstruction.process(CreateCursorResultSetInstruction.java:69) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.proc.ExecDynamicSqlInstruction$1.process(ExecDynamicSqlInstruction.java:218) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.proc.ProcedurePlan.processProcedure(ProcedurePlan.java:389) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.proc.ProcedurePlan.nextBatchDirect(ProcedurePlan.java:298) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.proc.ProcedurePlan.nextBatch(ProcedurePlan.java:270) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.relational.PlanExecutionNode.nextBatchDirect(PlanExecutionNode.java:118) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:150) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:472) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:348) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_91]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_91]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_91]
> Caused by: javax.script.ScriptException: TEIID31111 No such accessible property/method ISBN on class org.teiid.jdg.pojo.Book.
> at org.teiid.query.eval.TeiidScriptEngine$1.eval(TeiidScriptEngine.java:132) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.translator.object.ObjectUpdateExecution.evaluate(ObjectUpdateExecution.java:521) [translator-object-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> ... 47 more
> 12:34:07,146 WARN [org.teiid.MATVIEWS] (Worker0_QueryProcessorQueue225) org.teiid.jdbc.TeiidSQLException: TEIID30504 BookCacheSource: TEIID31111 No such accessible property/method ISBN on class org.teiid.jdg.pojo.Book.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4536) Support create schema with multiple statements
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4536?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4536:
---------------------------------------
Made some of the parsing changes to support this, but did not yet commit. For full round-tripping it would require that the ddl generation logic can optionally omit the semi-colons to directly associate the ddl to the schema. If we do this though, then we should have a direct correlation to the vdb.xml in ddl - as the biggest weakspot left is the handling of mixed metadata tags under a model element:
<model...
<metadata type="DDL">ddl</metadata>
<metadata ... other
</model>
will now translate to
create schema x;
import other ...
set schema x;
ddl
Note that the ddl is forced to logically happen after the other imports regardless of the tag ordering.
With this JIRA worked, we would instead have:
create schema x
ddl
import other tags ...
;
Such that the order is preserved and all schema scoped more concisely associated with the create.
> Support create schema with multiple statements
> ----------------------------------------------
>
> Key: TEIID-4536
> URL: https://issues.jboss.org/browse/TEIID-4536
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.3
>
>
> Create schema can support following create statements being directly associated rather than requiring an intermediate use schema
> create schema x
> create view ...
> ...
> ;
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4807) DDL format of a vdb lacks import information
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4807?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4807.
-----------------------------------
Resolution: Done
Rolled back the full DDL export for now as we need to be clear what the intent of that export is.
Since there is a specific conversion utility (which also had the .vdb logic rolled back) that lessens the need to introduce logic into the admin. Also as mentioned in TEIID-4765, we are not properly ensuring statement order from imported sources such that the ddl is generally valid when interpreted as statements.
That's not to say that we won't need functionality like this later.
> DDL format of a vdb lacks import information
> --------------------------------------------
>
> Key: TEIID-4807
> URL: https://issues.jboss.org/browse/TEIID-4807
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.3, 9.2.1
>
>
> Database and schema imports are not represented from the admin getSchema logic. It looks better that we still restrict this to just a schema for now.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4765) The notion of resolving order may need to be extended beyond a schema
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4765?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4765.
-----------------------------------
Fix Version/s: 9.2.1
Resolution: Done
Took a couple of steps in this direction. The most direct was not allowing the processing of general schema level ddl until after schema are declared and imports are processed. However we are still not fully in alignment with how metadata is processed from a vdb.xml. That can be made even more consistent with TEIID-4536
Another part of this is ddl generation is based upon resolving order, and not just type/name. Eventually if we round-trip through a live metadata system the order of the statements will matter - for example a referenced table or view must exist for use in later statements.
> The notion of resolving order may need to be extended beyond a schema
> ---------------------------------------------------------------------
>
> Key: TEIID-4765
> URL: https://issues.jboss.org/browse/TEIID-4765
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.3, 9.2.1
>
>
> With TEIID-4629 it is possible to interleave the definition of schema elements, which is not accounted for by the loading order - and will fail upon later validation/resolving.
> create virtual schema first;
> create virtual schema second;
> set schema second;
> create view x ...;
> set schema first;
> create view y as select * from x;
> the last statement will fail later as we'll try to resolve the schemas in order.
> A similar issue exists with create domain - TEIID-3624
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4788) DDL vdb is expensive to process
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4788?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4788.
-----------------------------------
Resolution: Done
Changed the logic to not create temporary Database or VDBMetadata representations - only 1 will be created as necessary. There is still a small performance issue in creating temporary MetadataFactory instances.
> DDL vdb is expensive to process
> -------------------------------
>
> Key: TEIID-4788
> URL: https://issues.jboss.org/browse/TEIID-4788
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.3, 9.2.1
>
>
> For many ddl operations, a fresh transformationmetadata instance is created, which requires converting the Database to runtime form. The larger the DDL vdb, the more expensive this becomes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4785) Add options through alter table in DDL does not work.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4785?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4785.
-----------------------------------
Resolution: Done
Delayed processing all alters until after imports are processed. Alters/create/drop against imported databases will fail as expected.
> Add options through alter table in DDL does not work.
> -----------------------------------------------------
>
> Key: TEIID-4785
> URL: https://issues.jboss.org/browse/TEIID-4785
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.2
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
> Fix For: 9.3, 9.2.1
>
>
> A command like the one below fails
> ALTER TABLE "teiidtest" options (add cardinality 1);
> This fails with message:
> This complains that the "group" teiidtest could not be found.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4552) Missing support for connection to Facebook via OAuth 2
by Jan Stastny (JIRA)
[ https://issues.jboss.org/browse/TEIID-4552?page=com.atlassian.jira.plugin... ]
Jan Stastny commented on TEIID-4552:
------------------------------------
I believe that has to be a change in the login module too, to support refresh_token-less use cases.
I remember that at least LinkedIn and Strava social sites, don't use refresh_token at all. I think they use long-lasting access_token instead.
Sort of a workaround would be to allow configuring access_token directly in the resource-adapter's security domain. Is this something we want, or are there some concerns?
To illustrate what I am talking about look at this diff: https://github.com/teiid/teiid/compare/master...jstastny-cz:oauth2-access...
The idea was to bypass refreshing the token, if access_token is provided from the configuration of security-domain.
> Missing support for connection to Facebook via OAuth 2
> ------------------------------------------------------
>
> Key: TEIID-4552
> URL: https://issues.jboss.org/browse/TEIID-4552
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.12.5
> Reporter: Lucie Fabrikova
> Assignee: Kylin Soong
> Fix For: 9.3
>
> Attachments: facebook3-vdb.xml, query, server.log, standalone.xml, teiid-oauth-util.sh-output
>
>
> I would like to connect to facebook resource adapter and configure OAuth 2 security domain for it; I used teiid-oauth-util.sh to generate the security domain (see attachment). Facebook doesn't support refresh tokens and in the generated code is refresh token's value "null".
> If I try to execute VDB with source pointing to such resource adapter I get error:
> ERROR [org.teiid.CONNECTOR] (Worker0_QueryProcessorQueue13) Connector worker process failed for atomic-request=Gapuea1/NRcn.6.3.0: org.apache.cxf.rs.security.oauth2.provider.OAuthServiceException
>
> (see server.log, facebook-vdb.xml, standalone.xml)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months