[JBoss JIRA] (TEIID-3763) WS connector security setting not work in Embedded
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3763?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-3763:
------------------------------------
After debug some code, I think if we add a Subject variable to WSManagedConnectionFactory,
{code}
WSManagedConnectionFactory mcf = new WSManagedConnectionFactory();
mcf.setSecurityType("OAuth");
mcf.setSubject(subject);
server.addConnectionFactory("java:/twitterDS", mcf.createConnectionFactory());
{code}
then in WSConnectionImpl add the following logic
{code}
if(mcf.getSubject() != null){
ConnectionContext.addSubject(mcf.getSubject() );
}
//setDispatchProperties
ConnectionContext.addSubject(null);
{code}
The Subject can get via picketbox standalone, more details refer to Embedded Security doc.
> WS connector security setting not work in Embedded
> --------------------------------------------------
>
> Key: TEIID-3763
> URL: https://issues.jboss.org/browse/TEIID-3763
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.13
> Reporter: Kylin Soong
> Assignee: Steven Hawkins
> Fix For: 8.13
>
>
> In WSConnectionImpl setDispatchProperties setting depend on Security Subject:
> {code}
> else if (this.mcf.getAsSecurityType() == WSManagedConnectionFactory.SecurityType.OAuth) {
> Subject subject = ConnectionContext.getSubject();
> if (subject != null) {
> }
> ...
> }
> {code}
> Note if run WS connector with security in Embedded, ConnectionContext.getSubject() return null, the cause exception throw.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (TEIID-3763) WS connector security setting not work in Embedded
by Kylin Soong (JIRA)
Kylin Soong created TEIID-3763:
----------------------------------
Summary: WS connector security setting not work in Embedded
Key: TEIID-3763
URL: https://issues.jboss.org/browse/TEIID-3763
Project: Teiid
Issue Type: Feature Request
Components: Misc. Connectors
Affects Versions: 8.13
Reporter: Kylin Soong
Assignee: Steven Hawkins
Fix For: 8.13
In WSConnectionImpl setDispatchProperties setting depend on Security Subject:
{code}
else if (this.mcf.getAsSecurityType() == WSManagedConnectionFactory.SecurityType.OAuth) {
Subject subject = ConnectionContext.getSubject();
if (subject != null) {
}
...
}
{code}
Note if run WS connector with security in Embedded, ConnectionContext.getSubject() return null, the cause exception throw.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (TEIID-3760) endswith defined with wrong return type
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3760?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3760:
----------------------------------
Description: The ends with function is marked as returning string instead of boolean. Also there is inconsistent accounting for parameter ordering in the odata logic. (was: The ends with function is marked as returning string instead of boolean.)
> endswith defined with wrong return type
> ---------------------------------------
>
> Key: TEIID-3760
> URL: https://issues.jboss.org/browse/TEIID-3760
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.3
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.12.1, 8.13
>
>
> The ends with function is marked as returning string instead of boolean. Also there is inconsistent accounting for parameter ordering in the odata logic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (TEIID-3760) endswith defined with wrong return type
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3760?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3760.
-----------------------------------
Resolution: Done
Changed the return to boolean.
Was looking at reversing the expected argument positions to match odata (some odata2 logic already assumed this, some odata4 was accounting for reversing) rather than following the locate function. However due to the breaking nature of that change (it's a publicly documented function) I updated the odata logic instead.
> endswith defined with wrong return type
> ---------------------------------------
>
> Key: TEIID-3760
> URL: https://issues.jboss.org/browse/TEIID-3760
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.3
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.12.1, 8.13
>
>
> The ends with function is marked as returning string instead of boolean.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (TEIID-3601) support larger row counts
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3601?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3601.
-----------------------------------
Resolution: Done
Updated the docs on limitations, count/ranking aggregations, and update counts.
> support larger row counts
> -------------------------
>
> Key: TEIID-3601
> URL: https://issues.jboss.org/browse/TEIID-3601
> Project: Teiid
> Issue Type: Feature Request
> Components: JDBC Driver, Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> In some extreme cases intermediate and final result sizes can exceed 2^31 - 1 rows. To support this we would need to make extensive changes:
> In the engine the tuplebuffer and logic related to indexing would need to change to long rather than int - this also touches things like join and insert processing.
> A new protocol version would be needed as resultmessages would need to use long rather than int indexing - however JDBC implicitly assumes int indexing such as with ResultSet.getRow.
> Temp table handling would need to be updated to support table sizes greater than max int.
> From a processing side, although not just related row counts, we would consider increasing the parallelism of the plan. The most fundamental way to do this is to partition source queries such that more data can be read in parallel from the source. This would require extension metadata to indicate the partitioning scheme. To take full advantage of such a change the plan itself would have to be paralellized such that as much processing as possible is performed on each partition (rather than the simple case in multi-source where the data is simply unioned back together in the parent node).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (TEIID-3760) endswith defined with wrong return type
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-3760:
-------------------------------------
Summary: endswith defined with wrong return type
Key: TEIID-3760
URL: https://issues.jboss.org/browse/TEIID-3760
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 8.3
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.12.1, 8.13
The ends with function is marked as returning string instead of boolean.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (TEIID-3666) VDB can deploy before datasource is bound
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3666?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3666.
---------------------------------
> VDB can deploy before datasource is bound
> -----------------------------------------
>
> Key: TEIID-3666
> URL: https://issues.jboss.org/browse/TEIID-3666
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7.3
> Environment: JDBC driver for datasource is deployed in deployments/ directory of standalone instance
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 8.12, 8.11.3
>
>
> A VDB can be deployed before the datasources it depends on are fully deployed and bound, resulting in the VDB never being marked as ACTIVE. This appears to be exclusive to environments where the JDBC driver for the datasource is deployed through use of the standalone deployments/ directory. If the driver is deployed as a module, then the risk of the issue is lowered or eliminated.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (TEIID-3759) Missing Apache Olingo dependency in Teiid 8.12.0.Final
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3759?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3759:
-------------------------------------
arg! yet another reason to get rid of the embedded zip file and replace with needed maven dependencies.
Currently I bring in all the lingo dependencies through the WAR building, I would need to reverse that to fix this.
> Missing Apache Olingo dependency in Teiid 8.12.0.Final
> ------------------------------------------------------
>
> Key: TEIID-3759
> URL: https://issues.jboss.org/browse/TEIID-3759
> Project: Teiid
> Issue Type: Enhancement
> Components: Embedded, OData
> Affects Versions: 8.12
> Reporter: Gary Gregory
> Assignee: Ramesh Reddy
>
> I think Teiid might have a missing Apache Olingo dependency:
> {noformat}
> java.lang.NoClassDefFoundError: org/apache/olingo/commons/api/edm/provider/CsdlBindingTarget
> at org.teiid.translator.odata4.ODataExecutionFactory.getMetadataProcessor(ODataExecutionFactory.java:140)
> at org.teiid.deployers.TranslatorUtil.buildTranslatorProperties(TranslatorUtil.java:280)
> at org.teiid.deployers.TranslatorUtil.buildTranslatorMetadata(TranslatorUtil.java:252)
> ...
> Caused by: java.lang.ClassNotFoundException: org.apache.olingo.commons.api.edm.provider.CsdlBindingTarget
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> ... 35 more
> {noformat}
> There is no Apache Olingo in {{optional/odata}} or {{lib/optional/odata4}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months