JBoss Community Archive (Read Only)

RHQ 4.9


Command Line Interface


This module is a command line shell to interact with the RHQ server.


  • CLI with startup arguments support

  • Scripts supported in JDK 1.6 script engine? (no 1.5 support?)

  • Execute external script

  • Log results

  • Login/Logout, Encryption support

Current Implementation

I was working on some client utilities a while back and I'd like to update them and check them in before they grow mold. As part of the EJB3 LazyInit workaround effort done for jaxws web service interfaces I wrote a Hibernate Detach Utility and an extended invoker layer that would make invocations and then detach objects before passing them back for serialization or jaxb binding. I also started a Client console interface based on the work mazz did for the same thing in the agent. What I have so far is below.

Some of the features/design questions:

I've got both builtin commands as well as our SLSB layer as remotely proxied scripting resources

You can run scripts using the javax.script engine system (we could choose to support maybe JS, Groovy and JRuby)

I'm exposing all our Stateless Session EJBs directly through JBoss Remoting because it was very easy to do... might be security concerns.

Do we really want to expose all EJBs... what about compatibility maintenance

Maybe we could use this to have a shell right in the webui?

unconnected> login rhqadmin rhqadmin localhost 7080
Calling remoting server with locator uri of: servlet://localhost:7080/jboss-remoting-servlet-invoker/ServerInvokerServlet
Login successful
localhost:7080> findResources ghinkle
Id     Name                                                         Avai
500050 ghinkle                                                      [UP]
500077 ghinkle  Embedded JBossWeb Server 2.0.0.GA  (        [UP]
500064 ghinkle  File System (local) /                               [UP]
500063 ghinkle  File System (local) /boot                           [UP]
500051 ghinkle RHQ Agent                                            [UP]
500054 ghinkle RHQ Server,  JBossAS 4.2.1.GA default ( [UP]
6 rows found
localhost:7080> exec pretty.print(ResourceTypeManager.getResourceTypesByPlugin('Postgres'));
creatable createDeletePolicy creationDataType deletable id name            plugin   singleton supportsManualAdd
true      BOTH               CONFIGURATION    true      0  Postgres Server Postgres false     false
true      BOTH               CONFIGURATION    true      0  Database        Postgres false     false
true      BOTH               CONFIGURATION    true      0  Table           Postgres false     false
true      BOTH               CONFIGURATION    true      0  User            Postgres false     false
4 rows found

localhost:7080> help
Command       Description
help          Help on the client and its commands
exec          Excecutes JavaScript commands using the various service interfaces
6 rows found
localhost:7080> exec print('Hello, World!')
localhost:7080> exec javax.swing.JOptionPane.showMessageDialog(null, 'Hello, World!');

localhost:7080> quit

Other Ideas

The CLI is a script execution engine. It should make our API look more like it was written in a scripting language... Its all about convenience.


Autocompletion should make it as easy to write a script as intellij does to code. First we need to hook the jline stuff in so its not printing out new lines as you autocomplete (do it in place). Next it should be able to autocomplete in a line of code... at least with variable setting at a minimum if we don't want to write a whole parser.

It should be updated to autocomplete out to the next missing parameter... and in that case offer matching type context objects. images/author/images/icons/emoticons/smile.gif one of the benefits of typing

Next it'd be cool if we could mark some parameters as optional (at the end obviously). The PageControl, for example, would be replaced with an unlimited PC if not provided. The autocomplete engine would look for ending PC's and show versions with and without.

Things that take resource type data would autocomplete to resource type info... e.g. plugin-name and type-name... Also, config property names could be completed in some conditions.

We could also skip the subjects probably and just always use the login subject. That's save a lot of complication images/author/images/icons/emoticons/smile.gif

DynaGroup query formats would be very nice to support for autocomplete too. Save users from looking up type names, property names, etc. Hopefully could hook in the same engine we want to build for the webui for that... but indicates the AC needs to be pluggable.

By the same token, it'd be useful to create "languages" for other subsystems. e.g. alerting could be described with a DSL and that would be bidrectionally editable with a real alert def. This would really simplify alert def stuff. AlertDefinitionManager.createAlert(resourceId, "availability goes down AND metric.threadCount > 100")


The CLI is already smart enough to print out the results of a line if they're not assigned. I wouldn't mind a $1 to get to those results.

Haven't built the ability to execute a script from disk... that's obviously needed. Perhaps a way to parameterize scripts... (this comes in handy when we put a UI on the scripts for automation)


We should have built in support for outputting results to common formats. At least CSV, excel or whatever. Common data exports like avail history, metric histories, etc. should be easily exportable and charted in excel.

CLI arguments

We need the CLI script/jar to accept a useful set of parameters on the command line as well as environment variables. Some programs support .xxx files that can save the password for autologin or whatever (might offer to save the password with j.u.prefs, encrypted of course).

You need to be able to pass in a script to execute obviously. You should also be able to pass one command to run as an argument.


Can you say terminal colors when outputting resources (red for down images/author/images/icons/emoticons/smile.gif )

Mark some properties in the entity as "summary" vs. "detail"... When printing to a basic table for tabular results we'd then use that to output just the most important entity properties.

JBoss.org Content Archive (Read Only), exported from JBoss Community Documentation Editor at 2020-03-13 08:04:05 UTC, last content change 2013-09-18 19:41:33 UTC.