[JBoss JIRA] (TEIID-4437) Convert Teiid build to use "feature-pack"
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4437?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4437:
---------------------------------------
The commit undid/removed TEIID-4472. I thought the ha/full-ha scripts needed to reference the profile in the cli - or is there a new way to accomplish that? Also what about the logging scripts?
> 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-4552) Missing support for connection to Facebook via OAuth 2
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4552?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-4552:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1390736|https://bugzilla.redhat.com/show_bug.cgi?id=1390736] from NEW to CLOSED
> 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
> Affects Versions: 8.12.5
> Reporter: Lucie Fabrikova
> Assignee: Steven Hawkins
> 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, 4 months
[JBoss JIRA] (TEIID-4562) Add OAuth 2 support for connection to Facebook
by Van Halbert (JIRA)
Van Halbert created TEIID-4562:
----------------------------------
Summary: Add OAuth 2 support for connection to Facebook
Key: TEIID-4562
URL: https://issues.jboss.org/browse/TEIID-4562
Project: Teiid
Issue Type: Feature Request
Affects Versions: 8.12.5
Reporter: Lucie Fabrikova
Assignee: Steven Hawkins
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, 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:
-------------------------------------
Committed the changes for this JIRA. [~kylin] can you verify and close this JIRA?
Let's start talking about how Swarm work will be based on this.
> 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 Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4561:
-------------------------------------
Summary: 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-4441) Add FTP/SFTP based access to the File Resource Adapter
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4441?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-4441 at 11/6/16 9:16 PM:
-------------------------------------------------------------
As below configuration segment
{code}
<connection-definition class-name="org.teiid.resource.adapter.file.FileManagedConnectionFactory" jndi-name="java:/marketdata-file" enabled="true" use-java-context="true" pool-name="fileDS">
<config-property name="ParentDirectory">
${jboss.home.dir}/teiidfiles/data/
</config-property>
<config-property name="AllowParentPaths">
true
</config-property>
</connection-definition>
{code}
The *ParentDirectory* must be a path on Local Disk, my thoughts, if we can expend and let this properties support
http://path/to/teiidfiles/data/
ftp://path/to/teiidfiles/data/
sftp://path/to/teiidfiles/data/
this will make file connector more flexible, am I on the right way?
was (Author: kylin):
As below configuration segment
{code}
<connection-definition class-name="org.teiid.resource.adapter.file.FileManagedConnectionFactory" jndi-name="java:/marketdata-file" enabled="true" use-java-context="true" pool-name="fileDS">
<config-property name="ParentDirectory">
${jboss.home.dir}/teiidfiles/data/
</config-property>
<config-property name="AllowParentPaths">
true
</config-property>
</connection-definition>
{code}
The *ParentDirectory* must be a path on Local Disk, my thoughts, if we can expend and these properties support
http://path/to/teiidfiles/data/
ftp://path/to/teiidfiles/data/
sftp://path/to/teiidfiles/data/
this will make file connector more flexible, am I on the right way?
> Add FTP/SFTP based access to the File Resource Adapter
> ------------------------------------------------------
>
> Key: TEIID-4441
> URL: https://issues.jboss.org/browse/TEIID-4441
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: Open To Community, 9.2
>
>
> This has been requested few times in the community, it would be nice to give provide this functionality. Using http://commons.apache.org/proper/commons-net/ seems to be right decision.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (TEIID-4441) Add FTP/SFTP based access to the File Resource Adapter
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4441?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-4441:
------------------------------------
As below configuration segment
{code}
<connection-definition class-name="org.teiid.resource.adapter.file.FileManagedConnectionFactory" jndi-name="java:/marketdata-file" enabled="true" use-java-context="true" pool-name="fileDS">
<config-property name="ParentDirectory">
${jboss.home.dir}/teiidfiles/data/
</config-property>
<config-property name="AllowParentPaths">
true
</config-property>
</connection-definition>
{code}
The *ParentDirectory* must be a path on Local Disk, my thoughts, if we can expend and these properties support
http://path/to/teiidfiles/data/
ftp://path/to/teiidfiles/data/
sftp://path/to/teiidfiles/data/
this will make file connector more flexible, am I on the right way?
> Add FTP/SFTP based access to the File Resource Adapter
> ------------------------------------------------------
>
> Key: TEIID-4441
> URL: https://issues.jboss.org/browse/TEIID-4441
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: Open To Community, 9.2
>
>
> This has been requested few times in the community, it would be nice to give provide this functionality. Using http://commons.apache.org/proper/commons-net/ seems to be right decision.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (TEIID-2578) add/remove schema elements
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2578?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2578:
---------------------------------------
Some general follow-ups here from some email discussions -
As implemented this is a distinct metadata system - it is they are managed entirely differently and has design decisions that are different from the current operation of deployment based vdbs.
An initial design choice was to follow the embedded model of having globally defined translators - which is something we need to decide is our forward direction or simply optional behavior.
Also metadata management is quite different - reloading metadata from a particular source will require manually dropping and reimporting a schema (or some equivalent manual high level operation) once the vdb is running. Also vdb import as a feature becomes difficult as the metadata is effectively being cloned and detached.
Reliance on a singleton service also is an issue for clustered embedded since that is a container concept.
A couple of high level decisions need to be made:
- do we want to move forward with the concept of Teiid completely owning the metadata for ddl based vdbs
- or do we want the metadata systems to work together more, such as having create being applicable against deployed vdbs.
- and in general what do want to do about concepts of metadata management from translators and vdb imports with ddl based vdbs
> add/remove schema elements
> --------------------------
>
> Key: TEIID-2578
> URL: https://issues.jboss.org/browse/TEIID-2578
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 9.2
>
>
> Schemas are currently static after load. Modifications can only happen with restarts or new versions. We should allow add/drop at runtime.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months