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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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

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.

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

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/8a6ccf7bc0903f196399aa439d... > > 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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/8a6ccf7bc0903f196399aa439d... >>> >>> 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > >