CLI.cmd() is a facade for the JBoss AS7 Command-line public API. I believe this API is at a lower level than where the "batch" command is handled, and it won't work that way.
But if you are using the CLI class I don't understand why you would need scripting. You have the full power of a programming language at your disposal. You already have a superset of the scripting capability.
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:
instead of this:
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.