[jboss-as7-dev] cli

[Brian Stansberry]

Apologies it's taken so long to give you feedback; I was out sick Friday.

I'll probably post a series of messages over the course of the week as I 
continue to experiment. I'm already using this to find bugs in the core 
stuff (e.g. inherited operations don't seem to be working anywhere other 
than the root address).

On 2/11/11 9:57 AM, Alexey Loubyansky wrote:
> Just FYI, in case of discussions, etc, I'm on PTO next week.
>   From Sunday to Thursday afternoon I won't have reliable Internet access.
>
> On 02/11/2011 04:50 PM, Alexey Loubyansky wrote:
>> I'd like to give a status update on what I've done so far, collect some
>> feedback and get a sense of direction for the roadmap.
>>
>> So, so far it's a primitive thing. There is a script jboss-admin.sh(bat)
>> under the JBOSS_HOME/bin. It starts a cli as a module (I found it easier
>> this way).
>>
>> First thing to do is to connect to the server. It's done with
>>
>> /connect [host]:[port]
>>
>> Default host is localhost, default port is 9999.
>>

On master, Kabir introduced a notion of different types of clients 
(DOMAIN, HOST, STANDALONE) which are implemented by passing an enum to 
ModelControllerClient.Factory.create(). We need to think through how 
that relates to this; whether that distinction is required and how to 
express it in the CLI.

The actual core API is the same between DOMAIN, HOST, STANDALONE (i.e. 
operations expressed in DMR and passed to the managed process and 
operation results in DMR are passed back); the real difference is just 
what the expected addresses and operations are. Right now the enum is 
just used to check that the client is connecting to the expected kind of 
process. Conceivably we don't need the DOMAIN/HOST/STANDALONE enum and 
we just count on users knowing what they are doing.

>> BTW, for the list of supported commands type /help. Besides /connection
>> and /help there are /quit and /prefix.
>>
>> Anything that doesn't start with '/' is considered an operation request.
>> Operation requests are currently following the format:
>>
>> [node-type=node-name [, node-type=node-name]*] : operation-name
>> ([name=value [, name=value]*])
>>
>> e.g.
>> profile=production,subsystem=threads,bounded-queue-thread-pool=pool1:write-core-threads(count=0,
>> per-cpu=20)
>>
>> Whitespaces between separators are insignificant.
>> If the address part is not specified then the ':' before the operation
>> name is optional.
>> If the operation has no arguments then the brackets '()' are optional.
>>
>> So, if we are at the root, just 'read-resource' will work.
>>
>> The result of the operation for now is logged by invoking toString() on
>> it, so it's formatted as on the wiki.
>>
>> About the /prefix command (it has an alias '/to'). It's an analogue of
>> the 'cd'. I.e. It specifies a node path prefix for an operation request
>> before it gets executed. E.g.
>>
>> /to subsystem=logging
>> read-resource
>>
>> will be equivalent to subsystem=logging:read-resource executed from the
>> root.
>>
>> It's also possible to end the prefix on the node type, e.g.
>> /to subsystem
>> logging:read-resource
>>
>> will be equivalent to the above.
>>
>> /to ~ - means go to the root.
>> '..' - go to the parent node.
>> .type - go to the node type of the current node.
>>
>> /prefix (or /to) w/o arguments will print the current prefix value. BTW,
>> the prefix is not verified to be a valid one (except from the syntax
>> point of view). If the prefix is wrong the operations will fail, of course.
>>

I like this /to stuff. :-) A prompt would be nice though, telling you 
where you are (probably just the last piece of the path).

>> That's about it for now. So, we talked a bit today with Emanuel and Max
>> about it. To improve usability we thought of adding:
>> - some sort of autocompletion (for the commands, node types/names,
>> operations);

Very nice to have, but something we can add after 7.0 if needed.

>> - having higher level management commands on top of the operation
>> requests, to avoid the verbose syntax of the operation requests for some
>> common things like deploy/undeploy, add a datasource, etc.

Yeah, I think besides polishing the details on the general purpose 
functionality you have, a few higher level commands are the most 
important things.

>> - use the jline for the input (currently it's BufferedReader.readLine()).
>>
>> Any other ideas, suggestions?
>>

Playing with this I immediately found myself hitting the up arrow to get 
the last command. Which of course didn't work. :-) That's not a 7.0 
thing either.

>> BTW, it's currently in my detyped2 branch.
>>
>> Thanks,
>> Alexey
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat