Thanks for your reply.

What I am trying to do is to build a library of reusable functions (groovy objects compiled in to a shared jar) that I can call from a groovy script. So I can use the same utility jar file for multiple servers in multiple environments. The scripts read the properties from a groovy config file. The goal is to automate and version control server configuration/management as much as we do with application deployments.

Specifically what I'm trying to do is to wrap several commands in a batch (transaction) so that if any part of it fails, the whole operation fails. For example: my deployment script will deploy a new datasource, then deploy a war file. If the war file fails to deploy, I would like to undo undo the datasource deployment (and anything else that was performed in the batch). It seems I could do that from the CLI prompt using the batch command but it doesn't seem to be available from the command-line public API (jboss-cli-client.jar).

I could also make sure every command I want to be included in a batch also has a corresponding rollback function and manage the transaction myself, but that seems like overkill and not very generic.

I could write my CLI operations in a text file and execute them from jboss-cli and use environment variables for my parameters. I don't like this option as much since it seems less flexible to me (you have to take care of the jboss-cli connection, setting the environment variables, you can't write user-friendly output of the commands etc.).

I could also have my groovy script create a text file of the commands, including the batch and run-batch commands and have my script execute that file in a separate process, but that also seems a little like a hack (though this might be my best option at this point).

The benefit is that after my library is completed, script commands will look like this:

utils.console.disableMgmtConsole()

instead of this:

/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)

That may not seem like a huge benefit but when you have parts of the CLI command that change from server to server and you are managing several application across 4 or 5 different environments, maintaining CLI text files starts to become bigger and more error prone.

Maybe this is a fools errand and won't be helpful, but other than the batch issue, it has been working well for me.