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
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?
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. 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
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.
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 )
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.