[teiid-issues] [JBoss JIRA] (TEIID-4311) Teiid Admin Api not support to create XA datasource on Jboss server.

[Kylin Soong (JIRA)]

    [ https://issues.jboss.org/browse/TEIID-4311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261633#comment-13261633 ] 

Kylin Soong edited comment on TEIID-4311 at 7/5/16 1:42 AM:
------------------------------------------------------------

> Although that is true some drivers allow you enter the "connection-url" for the data source, not all data sources do.

Yes, I agree, there are 2 kinds of properties, one can be set as datasource attributes, the other is xa-datasource-properties, note that due to change in wildfly 10, the adding of xa ds need a composite operations, take mysql as example, you have to execute 5 line cli as below
{code}
batch
/subsystem=datasources/xa-data-source=mysqlXADS:add(jndi-name="${db.jndi_name}",  driver-name=mysqlXA, user-name="${db.user}", password="${db.password}", use-java-context=true)
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=DatabaseName:add(value="${db.database_name}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=PortNumber:add(value="${db.port}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=ServerName:add(value="${db.host}")
run-batch
{code}

An alternative is use "xa-data-source add" which like reference pull request.

> The CLI is simple enough to write in code and include template properties in-line and write readable code

>From my side, I know each method are try to build a request, but need lot time to know how it be finished, as 
    http://ksoong.org/wildfly-samples/subsystem/img/WildFly_Subsystem_Architecture.png
Wildfly tree layer Architecture, in this 4 layer tree, there may have more than 10 management cli
{code}
:some-operation
:read-attribute(name=som-attr)
:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name=som-attr)
/subsystem=tracker:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name=som-attr)
/subsystem=tracker/X:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name=som-attr)
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value=some_value)
{code}
In current design, it have to hard code to create more than 10 private methods to form the request one by one, but if you use a file to hold all the clis in advance
{code}
:some-operation
:read-attribute(name={0})
:write-attribute(name=som-attr, value={0})
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name={0})
/subsystem=tracker:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name={0})
/subsystem=tracker/X:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name={0})
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value={0})
{code}
Which now you just need to get the cli from file, replace the parameter, and use the unique method to build request. Another benefit is easy to maintain, if one of cli has changed, we just need update cli in the file, do not need read the code and change the code. Also use a file to separate/pre-structure logic is a usual scenario in software, like BPM use a file define the business logic rather than use great number of hard code to define business, BRMS use a file define business rules rather than use great number of hard code to make business decision.

> especially if number of the "xa-data-source-property" are dynamic in count which are provided by user.
{code}
createXADataSource=xa-data-source add --name={0} --driver-name={1} --jndi-name={2} {3} --xa-datasource-properties=[{4}]
{code}
* 0, 1, 2  - Required argument
* 3 - Optional argument
* 4 - at lease define 1 properties base on wildfly 10 datasource change.
{code}
public void createXADataSource(String deploymentName, final String driverName, final Properties properties)
{code}
0, 1, 2 come from deploymentName and driverName; 3 come from properties, the left properties will go into 4.


was (Author: kylin):
> Although that is true some drivers allow you enter the "connection-url" for the data source, not all data sources do.

Yes, I agree, there are 2 kinds of properties, one can be set as datasource attributes, the other is xa-datasource-properties, note that due to change in wildfly 10, the adding of xa ds need a composite operations, take mysql as example, you have to execute 5 line cli as below
{code}
batch
/subsystem=datasources/xa-data-source=mysqlXADS:add(jndi-name="${db.jndi_name}",  driver-name=mysqlXA, user-name="${db.user}", password="${db.password}", use-java-context=true)
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=DatabaseName:add(value="${db.database_name}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=PortNumber:add(value="${db.port}")
/subsystem=datasources/xa-data-source=mysqlXADS/xa-datasource-properties=ServerName:add(value="${db.host}")
run-batch
{code}

An alternative is use "xa-data-source add" which like reference pull request.

> The CLI is simple enough to write in code and include template properties in-line and write readable code

>From my side, I know each method are try to build a request, but need lot time to know how it be finished, as 
    http://ksoong.org/wildfly-samples/subsystem/img/WildFly_Subsystem_Architecture.png
Wildfly tree layer Architecture, in this 4 layer tree, there may have more than 10 management cli
{code}
:some-operation
:read-attribute(name=som-attr)
:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name=som-attr)
/subsystem=tracker:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name=som-attr)
/subsystem=tracker/X:write-attribute(name=som-attr, value=some_value)
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name=som-attr)
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value=some_value)
{code}
In current design, it have to hard code to create more than 10 private methods to form the request one by one, but if you use a file to hold all the clis in advance
{code}
:some-operation
:read-attribute(name={0})
:write-attribute(name=som-attr, value={0})
/subsystem=tracker:some-operation
/subsystem=tracker:read-attribute(name={0})
/subsystem=tracker:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X:some-operation
/subsystem=tracker/X:read-attribute(name={0})
/subsystem=tracker/X:write-attribute(name=som-attr, value={0})
/subsystem=tracker/X/Y:some-operation
/subsystem=tracker/X/Y:read-attribute(name={0})
/subsystem=tracker/X/Y:write-attribute(name=som-attr, value={0})
{code}
Which now you just need to get the cli from file, replace the parameter, and use the unique method to build request. Another benefit is easy to maintain, if one of cli has changed, we just need update cli in the file, do not need read the code and change the code. Also use a file to separate/pre-structure logic is a usual scenario in software, like BPM use a file define the business logic rather than use great number of hard code to define business, BRMS use a file define business rules rather than use great number of hard code to make business decision.

> especially if number of the "xa-data-source-property" are dynamic in count which are provided by user.
{code}
createXADataSource=xa-data-source add --name={0} --driver-name={1} --jndi-name={2} {3} --xa-datasource-properties=[{4}]
{code}
* 0, 1, 2  - Required argument
* 3 - Optional argument
* 4 - at lease define 1 properties base on wildfly 10 datasource change.

> Teiid Admin Api not support to create XA datasource on Jboss server.
> --------------------------------------------------------------------
>
>                 Key: TEIID-4311
>                 URL: https://issues.jboss.org/browse/TEIID-4311
>             Project: Teiid
>          Issue Type: Bug
>          Components: AdminApi
>    Affects Versions: 8.13.x
>            Reporter: Prakash Jape
>            Assignee: Kylin Soong
>             Fix For: 9.1, 9.0.2
>
>
> Teiid Admin api does not support or does not have capability to create XA datasource on Jboss server.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)