[ https://issues.jboss.org/browse/TEIID-4311?page=com.atlassian.jira.plugin... ] Kylin Soong edited comment on TEIID-4311 at 7/5/16 1:40 AM: ------------------------------------------------------------ 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. http://ksoong.org/wildfly-samples/subsystem/img/WildFly_Subsystem_Archite... 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. {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. was (Author: kylin): 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. http://ksoong.org/wildfly-samples/subsystem/img/WildFly_Subsystem_Archite... 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. -- This message was sent by Atlassian JIRA (v6.4.11#64026)