[JBoss JIRA] (TEIID-4718) Enable JDG resource adapter to support HotRod SSL
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4718?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-4718:
------------------------------------
With JDG 7.1, it supports a new method: .sniHostName("domain1") when configuring the JDG remoteCacheManager.
Example:
{code}
ConfigurationBuilder clientBuilder = new ConfigurationBuilder();
clientBuilder
.addServer()
.host("127.0.0.1")
.port(hotrodServer.getPort())
.socketTimeout(3000)
.security()
.ssl()
.enabled(sslClient)
.sniHostName("domain1")
.trustStoreFileName("truststore.jks")
.trustStorePassword("secret".toCharArray());
remoteCacheManager = new RemoteCacheManager(clientBuilder.build());
{code}
In order to support JDG 7.1 and JDG 6.6, have 2 choices:
- lazily instantiate the class that configures JDG cache based on JDG version being used, but will be problematic in unit testing
- create a new resource-adapter specifically for for JDG 7.1
> Enable JDG resource adapter to support HotRod SSL
> -------------------------------------------------
>
> Key: TEIID-4718
> URL: https://issues.jboss.org/browse/TEIID-4718
> Project: Teiid
> Issue Type: Enhancement
> Components: JDG Connector
> Affects Versions: 9.2
> Reporter: Van Halbert
> Assignee: Van Halbert
>
> Enable the JDG resource adapter to support the HotRod encryption [1]
> http://infinispan.org/docs/9.0.x/infinispan_server_guide/infinispan_serve...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (TEIID-4719) Add a ddl equivalent to the metadata tag
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4719?page=com.atlassian.jira.plugin... ]
Ramesh Reddy edited comment on TEIID-4719 at 1/25/17 8:14 PM:
--------------------------------------------------------------
Actually the current import syntax looks like
{code}
IMPORT FOREIGN SCHEMA remote_schema
[ { LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM SERVER server_name
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
{code}
So to adopt this, how about
{code}
IMPORT FOREIGN SCHEMA remote_schema
[ { LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM REPOSITORY {repo}
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
{code}
OPTIONS would need to have the \{arg\} depending upon the \{repo\} type.
was (Author: rareddy):
Actually the current import syntax looks like
{code}
IMPORT FOREIGN SCHEMA remote_schema
[ { LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM SERVER server_name
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
{code}
So to adopt this it will be
{code}
IMPORT SCHEMA remote_schema
[ { LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM {repo}
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
{code}
OPTIONS would need to have the \{arg\} depending upon the \{repo\} type.
> Add a ddl equivalent to the metadata tag
> ----------------------------------------
>
> Key: TEIID-4719
> URL: https://issues.jboss.org/browse/TEIID-4719
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
>
> Generally we'll need something that is equivalent to the metadata tag - that can specify a repo and options. In a zip deployment this will allow splitting the ddl over multiple files.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (TEIID-4719) Add a ddl equivalent to the metadata tag
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4719?page=com.atlassian.jira.plugin... ]
Ramesh Reddy edited comment on TEIID-4719 at 1/25/17 8:09 PM:
--------------------------------------------------------------
Actually the current import syntax looks like
{code}
IMPORT FOREIGN SCHEMA remote_schema
[ { LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM SERVER server_name
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
{code}
So to adopt this it will be
{code}
IMPORT SCHEMA remote_schema
[ { LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM {repo}
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
{code}
OPTIONS would need to have the \{arg\} depending upon the \{repo\} type.
was (Author: rareddy):
Actually the current import syntax looks like
{code}
IMPORT FOREIGN SCHEMA remote_schema
[ \{ LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM SERVER server_name
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
{code}
So to adopt this with our {repo} it will be
{code}
IMPORT SCHEMA remote_schema
[ \{ LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM {repo}
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
{code}
OPTIONS would need to have the {arg} depending upon the {repo} type.
> Add a ddl equivalent to the metadata tag
> ----------------------------------------
>
> Key: TEIID-4719
> URL: https://issues.jboss.org/browse/TEIID-4719
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
>
> Generally we'll need something that is equivalent to the metadata tag - that can specify a repo and options. In a zip deployment this will allow splitting the ddl over multiple files.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (TEIID-4719) Add a ddl equivalent to the metadata tag
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4719?page=com.atlassian.jira.plugin... ]
Ramesh Reddy edited comment on TEIID-4719 at 1/25/17 8:08 PM:
--------------------------------------------------------------
Actually the current import syntax looks like
{code}
IMPORT FOREIGN SCHEMA remote_schema
[ \{ LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM SERVER server_name
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
{code}
So to adopt this with our {repo} it will be
{code}
IMPORT SCHEMA remote_schema
[ \{ LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM {repo}
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
{code}
OPTIONS would need to have the {arg} depending upon the {repo} type.
was (Author: rareddy):
Actually the current import syntax looks like
{code}
IMPORT FOREIGN SCHEMA remote_schema
[ { LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM SERVER server_name
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
{code}
So to adopt this with our {repo} it will be
{code}
IMPORT SCHEMA remote_schema
[ { LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM {repo}
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
{code}
OPTIONS would need to have the {arg} depending upon the {repo} type.
> Add a ddl equivalent to the metadata tag
> ----------------------------------------
>
> Key: TEIID-4719
> URL: https://issues.jboss.org/browse/TEIID-4719
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
>
> Generally we'll need something that is equivalent to the metadata tag - that can specify a repo and options. In a zip deployment this will allow splitting the ddl over multiple files.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (TEIID-4719) Add a ddl equivalent to the metadata tag
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4719?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4719:
-------------------------------------
Actually the current import syntax looks like
{code}
IMPORT FOREIGN SCHEMA remote_schema
[ { LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM SERVER server_name
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
{code}
So to adopt this with our {repo} it will be
{code}
IMPORT SCHEMA remote_schema
[ { LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM {repo}
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
{code}
OPTIONS would need to have the {arg} depending upon the {repo} type.
> Add a ddl equivalent to the metadata tag
> ----------------------------------------
>
> Key: TEIID-4719
> URL: https://issues.jboss.org/browse/TEIID-4719
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
>
> Generally we'll need something that is equivalent to the metadata tag - that can specify a repo and options. In a zip deployment this will allow splitting the ddl over multiple files.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (TEIID-4629) Offer a ddl solution to replace the vdb.xml
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4629?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4629:
-------------------------------------
Since we are working in single context, I was less inclined for that change, but I will also add that shortly.
> Offer a ddl solution to replace the vdb.xml
> -------------------------------------------
>
> Key: TEIID-4629
> URL: https://issues.jboss.org/browse/TEIID-4629
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine, Server
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Fix For: 9.2
>
>
> Based upon the work on TEIID-2578 we should first offer the ability to replace the vdb.xml with ddl. We can additionally include some of the work to represent additional pieces of the vdb as api level metadata objects (instead of in the admin layer) where possible. Ideally this should support as much alter functionality as possible.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (TEIID-4629) Offer a ddl solution to replace the vdb.xml
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4629?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4629:
---------------------------------------
For conformance, we should also not have CREATE DATABASE set the current database.
> Offer a ddl solution to replace the vdb.xml
> -------------------------------------------
>
> Key: TEIID-4629
> URL: https://issues.jboss.org/browse/TEIID-4629
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine, Server
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Fix For: 9.2
>
>
> Based upon the work on TEIID-2578 we should first offer the ability to replace the vdb.xml with ddl. We can additionally include some of the work to represent additional pieces of the vdb as api level metadata objects (instead of in the admin layer) where possible. Ideally this should support as much alter functionality as possible.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months