I've been using the Java Management API to create a datasource and noticed that the 'enabled' attribute is set to false, even if I specify it.
This is what I'm doing:
ModelControllerClient client = ModelControllerClient.Factory.create(InetAddress.getByName("localhost"), 9999, callbackHandler); ModelNode op = new ModelNode(); op.get("operation").set("add"); ModelNode address = op.get("address"); address.add("subsystem", "datasources"); address.add("data-source", dsname); op.get("jndi-name").set("java:jboss/datasources/" + dsname); op.get("driver-name").set("h2"); op.get("enabled").set(true); op.get("pool-name").set("MigrateDS"); op.get("connection-url").set("jdbc:h2:mem:test;DB_CLOSE_DELAY=-1"); ModelNode retVal = client.execute(op);
This will create a disabled datasource when executed. Looking at line 143 of AbstractDataSourceAdd the enabled attribute is overwritten and set to false:
Was there an issue with enabling a datasource when using the Java API?
It's intentional: if you read operation description for add you can see that enabled is no more a parameter.
All DataSources are added as NOT enbled and the user have to explicit invoke enable operation to get it deployed (and register to jndi).
The reason for that is we need this deployed-but-not-enabled state to add connection-properties if they are needed (and xa-datasurce-properties for XA ds).Moreover this state permit to edit any attribute and add/remove subresources (connection-properties and xa-datasource-properties) without reload all tje server. We provide both enable and disable operation to manage transitions.
AFAIK web console is hiding this double operation and also cli should do that in future. Also xml parsing is hiding this double operation in case the ds is declared enabled in standalone.xml.
Of course if you are using directly API you have to take care of this extra effort.