[jboss-as7-dev] cli

[Kabir Khan]

On 14 Feb 2011, at 17:51, Brian Stansberry wrote:

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

The reason I added that was the host management socket. If the DC is local, both HC and DC requests will come in on the same socket. We need some differentiator to know if a request should go to the HC or the DC. 

> 
>>> 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
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev