[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)
9 years
[JBoss JIRA] (TEIID-4799) Accessing a JDBC source via ODATA creates stack trace in log
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4799?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4799:
---------------------------------------
The source type may be relevant as well.
> Accessing a JDBC source via ODATA creates stack trace in log
> -------------------------------------------------------------
>
> Key: TEIID-4799
> URL: https://issues.jboss.org/browse/TEIID-4799
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.8.6_3
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Attachments: stacktrace.txt
>
>
> When doing a get to a odata endpoint that will use a jdbc connection in data virtualization, there will be a transaction related stacktrace in the logs. This does not seem to create a problem but is confusing.
> Version-Release number of selected component (if applicable):
> 8.12.x
> How reproducible:
> Steps to Reproduce:
> 1. Add a JDBC datasource model in the Teiid Design Perspective
> 2. Add a Teiid Metadata view model using the JDBC source model
> 3. Deploy the view model in a VDB
> 4. Access the view model via an odata call
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[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 commented on TEIID-4807:
---------------------------------------
> This always been the case, we always returned the metadata, not import information.
But you are comparing apples to oranges. In the old case the admin method was asking for the ddl specifically for a single schema. In the new case you are returning the metadata for the entire vdb. In the xml case you are returning a different set of metadata that the ddl case - that is not consistent.
> What is missing? I am failing to understand that, can please explain?
The model element will still include all of the metadata tags, including "imports", and ddl - plus the additional full ddl. That's not likely what the user would want.
> same here, I do not understand this.
There are two different usages being considered there. One is informational - what is the schema contents for a given model. The other is the conversion aspect. It's the latter we we are not offering a 1-1 conversion. We are offering ddl that does not reflect the deployment state of the vdb, but the runtime state. That is functionally different until we only have a full online metadata system.
> 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)
9 years
[JBoss JIRA] (TEIID-4807) DDL format of a vdb lacks import information
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4807?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4807:
-------------------------------------
>If you specify XML, you'll effectively get the vdb.xml with extra schema information.
This always been the case, we always returned the metadata, not import information. Why this harmful? In Teiid, we always maintained that deployment artifact is different than the runtime representation.
>If you specify ddl, you won't get the schema information,
What is missing? I am failing to understand that, can please explain?
>Which is important that we offer something that is a full representation.
same here, I do not understand this.
> 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)
9 years
[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 commented on TEIID-4807:
---------------------------------------
> Even with the xml format, get-schema always returned the schema not import information, this enhancement just expanded to whole vdb.
That is not correct, it's not a consistent output. If you specify XML, you'll effectively get the vdb.xml with extra schema information. If you specify ddl, you won't get the schema information, but not the full equivalent of the vdb.xml or vdb.ddl.
> IMO these utilities are important to get users converted over to using DDL
Which is important that we offer something that is a full representation. If we move fully in the direction of undoing our notion of metadata management in favor of an online metadata system, then this
> 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)
9 years
[JBoss JIRA] (TEIID-4807) DDL format of a vdb lacks import information
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4807?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4807:
-------------------------------------
I do not I agree with this. GetSchema call is not vdb export, it is call to get the current vdb schema. This is akin to say if .vdb is deployed get me one with .INDEX file. IMO these utilities are important to get users converted over to using DDL. Even with the xml format, get-schema always returned the schema not import information, this enhancement just expanded to whole vdb.
ConvertVDB utility already does what you are saying, it keeps the import statements in tact.
> 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)
9 years
[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 updated TEIID-4536:
----------------------------------
Priority: Critical (was: Minor)
This will be the only way to resolve TEIID-4765 for now. This will further restrict what ddl is supported in a vdb.ddl file, but it will fully map to currently supported constructs.
> 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)
9 years