[jboss-as7-dev] cli

[Brian Stansberry]

The current state of it has been pushed into master.

On 2/22/11 9:52 AM, Jason T. Greene wrote:
> Sweet. I can't wait to play with this.
>
> On 2/22/11 9:44 AM, Brian Stansberry wrote:
>> You rock. :-)
>>
>> On 2/22/11 9:28 AM, Alexey Loubyansky wrote:
>>> Ok, I created a branch 'cli' (from your cli-on-master), added
>>>      jline module,
>>>      command history,
>>>      tab-completion of commands starting with '/'
>>>      and command prompt including the current prefix.
>>>
>>> On 02/15/2011 03:58 PM, Brian Stansberry wrote:
>>>> Your detyped2 branch was a bit behind where master is now, so I
>>>> cherry-picked your commits onto a branch created from master and pushed
>>>> that out:
>>>>
>>>> https://github.com/bstansberry/jboss-as/commits/cli-on-master
>>>>
>>>> When you can back we can sort branching; should be simple.
>>>>
>>>> I pushed one non-merging related commit on that branch[1], which was a
>>>> quick and dirty fix to allow using other DMR types than ModelTyp.STRING
>>>> as param values. That was mostly to make it easy for me to experiment;
>>>> we can decide whether that's the right approach when you get back.
>>>>
>>>> [1]
>>>> https://github.com/bstansberry/jboss-as/commit/8a6ccf7bc0903f196399aa439de9a3e6cc5cfd76
>>>>
>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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);
>>>>>> - 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.
>>>>>> - use the jline for the input (currently it's BufferedReader.readLine()).
>>>>>>
>>>>>> Any other ideas, suggestions?
>>>>>>
>>>>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> 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