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.
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
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 (0.0.0.0) [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 (0.0.0.0:2099) [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
logout
exec Excecutes JavaScript commands using the various service interfaces
login
findResources
quit
6 rows found
localhost:7080> exec print('Hello, World!')
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
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")
Exec
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)
Export
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.
Fancyness
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.