Is there a CLI model that I can import to write typesafe scripts?

[sboscarine]

Are there typesafe objects available that represent all the values avaiable when setting a DataSource...or any other JBoss domain objects?  Surely you parse these comands to rich objects.  Do you expose them to the users?

I want to write an installer for my application with compiler-safe attributes so that if JBoss changes their CLI model down the road, dropping or renaming an attribute, I can discover this via a compiler instead of at Runtime or by a user complaining. 

When I run:

/subsystem=datasources/data-source=myDS:read-resource

I get:

[standalone@localhost:9999 /] /subsystem=datasources/data-source=myDS:read-resource
{
    "outcome" => "success",
    "result" => {
        "allocation-retry" => undefined,
        "allocation-retry-wait-millis" => undefined,
        "allow-multiple-users" => undefined,
        "background-validation" => undefined,
        "background-validation-millis" => undefined,
        "blocking-timeout-wait-millis" => undefined,
        "check-valid-connection-sql" => "select 1 from dual",
        "connection-properties" => undefined,
        "connection-url" => "jdbc:oracle:thin:@localhost:1521:XE",
        "datasource-class" => undefined,
        "driver-class" => undefined,
        "driver-name" => "oracle",
        "enabled" => true,
        "exception-sorter-class-name" => "org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter",
        "exception-sorter-properties" => undefined,
        "flush-strategy" => "FailingConnectionOnly",
        "idle-timeout-minutes" => undefined,
       "jndi-name" => "java:/drm-data_source",
        "jta" => true,
        "max-pool-size" => 50,
        "min-pool-size" => 2,
        "new-connection-sql" => undefined,
        "password" => "sboscarine",
        "pool-prefill" => undefined,
        "pool-use-strict-min" => undefined,
        "prepared-statements-cache-size" => undefined,
        "query-timeout" => undefined,
        "reauth-plugin-class-name" => undefined,
        "reauth-plugin-properties" => undefined,
        "security-domain" => undefined,
        "set-tx-query-timeout" => false,
        "share-prepared-statements" => false,
        "spy" => false,
        "stale-connection-checker-class-name" => undefined,
        "stale-connection-checker-properties" => undefined,
        "track-statements" => "NOWARN",
        "transaction-isolation" => undefined,
        "url-delimiter" => undefined,
        "url-selector-strategy-class-name" => undefined,
        "use-ccm" => true,
        "use-fast-fail" => false,
        "use-java-context" => false,
        "use-try-lock" => undefined,
        "user-name" => "sboscarine",
        "valid-connection-checker-class-name" => undefined,
        "valid-connection-checker-properties" => undefined,
        "validate-on-match" => false,
        "statistics" => {
            "jdbc" => undefined,
            "pool" => undefined
        }
    }
}

I'd love to have an enum or bean that represents these values.  Are there any exposed to the users?

Thanks,
Steven

[nickarls]

https://github.com/jbossas/jboss-as/blob/master/connector/src/main/java/org/jboss/as/connector/subsystems/datasources/Constants.java

Of course it's exposed! It's Open Source! ;-)

It's in the module "org.jboss.as.connector" in jboss-as-connector-7.1.1.Final.jar.

Since it's not a published API, there are no guarantees that the actual contstant names will stay the same, though.

[aloubyansky]

AS7 management is by design detyped. So, even the native management tools, like the console or cli, would not fail during the build if there was an incompatible change in one of the management interfaces.

In the future such changes will happen, of course. To check the compatibility, the client will have to consult the version of the subsystem or the resource.

If you want to re-use some of the CLI features in your application, it does expose a public API https://community.jboss.org/wiki/JBossAS7Command-linePublicAPI

[sboscarine]

Hello Alexey,

I am using the public API now. 

<dependency>
  <groupId>org.jboss.as</groupId>
  <artifactId>jboss-as-cli</artifactId>
  <version>7.2.0-Alpha</version>
</dependency>

I am very happy RedHat offers it, but it really seems like just a mechanism to pass the CLI Strings through.  I am sure it's a nice start, but in using it, my app looks just like my CLI scripts so far.

The problem is that I would be doing my employer a disservice if I trusted RedHat to maintain those exact Strings through the years and it will be very costly for me to verify on every container point-release that RedHat plans on releasing that they want to support for their users.  Like all app providers, we're hoping to be viable and support our wares on EAP7, 8, etc.

I am making the assumption these CLI String commands get bound to a rich model at some point and am hoping RedHat exposes them in an easy-to-consume bean so I can rely on my compiler to tell me when

/subsystem=datasources/data-source=mydata_source:add( jndi-name=java:/mydata_source,  connection-url=jdbc:oracle:thin:@localhost:1521:XE, user-name=ChangeMePlease,  password=ChangeMePlease,  use-java-context=false,  check-valid-connection-sql="select 1 from dual", min-pool-size=2,max-pool-size=50,driver-name=oracle,exception-sorter-class-name=org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter, flush-strategy=FailingConnectionOnly)

... is no longer valid were any of these params to get renamed or dropped.

I haven't yet tried Nicklas' suggestion, but otherwise from what I can gather(https://community.jboss.org/wiki/AdvancedCLIScriptingWithGroovyRhinoJythonEtc), I need to assemble Strings that match the format above.

Thanks,

Steven

[ssilvert]

If you want to stay away from CLI command Strings you can use DMR directly. 

See the last example in JBoss AS7 Command-line public API.  This shows client.execute(deployRequest);  where deployRequest is a ModelNode.  The example shows building the deployRequest via a CLI command string.  But you can also build a ModelNode manually using the DMR API.  See Format of a Detyped Operation Request.

But since the request is detyped anyway, I think either method gives you roughly the same level of maintainability.  The management operations must continue to be backward compatible at least through the AS7.x line.

Stan