[wildfly-dev] CLI Non-Interactive Output Changes

Edward Wertz ewertz at redhat.com
Fri Sep 4 14:20:18 EDT 2015



----- Original Message -----
> From: "Alexey Loubyansky" <alexey.loubyansky at redhat.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Friday, September 4, 2015 11:37:16 PM
> Subject: Re: [wildfly-dev] CLI Non-Interactive Output Changes
> 
> On 09/04/2015 04:46 PM, Brian Stansberry wrote:
> > How hard would it be to get rid of that last line? I much prefer
> > the
> > output with the prompt, but I think the last line issue is a valid
> > concern.
> >
> > Does this have any impact on embedded uses of the CLI?

No. The existing 'handle(line)' API method that a java app would be using is unchanged. The new functionality adds an API method, 'pushToInput(line)', and handle the non-interactive mode now.

> >
> > Most importantly, can it be turned off?
> >
> > I ask, because I'm concerned about things like this:
> >
> > $ bin/jboss-cli.sh
> > --commands=connect,/server-group=main-server-group:read-resource
> > {
> >       "outcome" => "success",
> >       "result" => {
> >           "management-subsystem-endpoint" => false,
> >           "profile" => "full",
> >           "socket-binding-default-interface" => undefined,
> >           "socket-binding-group" => "full-sockets",
> >           "socket-binding-port-offset" => 0,
> >           "deployment" => undefined,
> >           "deployment-overlay" => undefined,
> >           "jvm" => {"default" => undefined},
> >           "system-property" => undefined
> >       }
> > }
> >
> > That response can be fairly simply parsed and analyzed, since it's
> > the
> > direct representation of a ModelNode. Adding a line of text breaks
> > that.
> 
> I had the same thought.
> When multiple command lines passed into non-interactive mode, the
> proposed output does look easier to understand and navigate. In case
> of
> a single line, it looks even a bit strange to me.
> 
> Thanks,
> Alexey
> > Perhaps most use cases that would be doing that kind of
> > parsing/analysis
> > would be embedding the CLI in a java app that does that work, since
> > then
> > you can easily use ModelNode itself. But not necessarily all. Our
> > low
> > level op responses have a well known format and the parsing isn't
> > rocket
> > science.
> >

I can remove the last line, that output would look like this:

[joe at localhost bin]$ ./jboss-cli.sh --commands=connect,/server-group=main-server-group:read-resource
[disconnected /] connect
[domain at localhost:9990 /] /server-group=main-server-group:read-resource
{
    "outcome" => "success",
    "result" => {
        "management-subsystem-endpoint" => false,
        "profile" => "default",
        "socket-binding-default-interface" => undefined,
        "socket-binding-group" => "standard-sockets",
        "socket-binding-port-offset" => 0,
        "deployment" => undefined,
        "deployment-overlay" => undefined,
        "jvm" => {"default" => undefined},
        "system-property" => undefined
    }
}

I can cobble together existing options, remove the prompt and mask the input, which would look like this:

[joe at localhost bin]$ ./jboss-cli.sh --commands=connect,/server-group=main-server-group:read-resource


{
    "outcome" => "success",
    "result" => {
        "management-subsystem-endpoint" => false,
        "profile" => "default",
        "socket-binding-default-interface" => undefined,
        "socket-binding-group" => "standard-sockets",
        "socket-binding-port-offset" => 0,
        "deployment" => undefined,
        "deployment-overlay" => undefined,
        "jvm" => {"default" => undefined},
        "system-property" => undefined
    }
}

Which is very close to the existing output, but includes a newline for each command that gets processed. This could be enabled with a new argument, '--only-output' or something, that's only applicable to non-interactive mode.

In order to remove the newlines, I'd have to make AESH changes to not echo input back to the output stream. I'm not sure how easy that is to do yet, but I haven't found a quick solution that would make sense. It's difficult to predict someone will want to use your UI project as something other than a UI, which would always want to echo input this way, so this might require a redesign of the input processing to create a comprehensive way to handle it.

-- Joe

> >
> > On 9/4/15 9:04 AM, Edward Wertz wrote:
> >> Hello All,
> >>
> >> I've been doing some work on the non-interactive mode of the CLI,
> >> when using --file or --commands, and since the current version of
> >> the work changes the output slightly I'd like to get some
> >> opinions on it. The changes are necessary in order to pass the
> >> non-interactive commands through the AESH console system, which
> >> enables additional functionality like the history file and
> >> 'alias' command. If not done, the non-interactive mode
> >> functionality won't behave the same as the interactive mode.
> >> Commands handled by AESH like 'alias' will be missing entirely,
> >> and non-interactive commands won't show up in the cli history
> >> file. If AESH is expanded further in the future, more commands
> >> will be inaccessible in non-interactive mode.
> >>
> >> The existing output for this mode only includes the command
> >> output. It doesn't include the commands entered, or the
> >> interactive command prompts like '[disconnected /]'. Exampled
> >> like so:
> >>
> >> [joe at localhost bin]$ ./jboss-cli.sh
> >> --commands=version,connect,version,"echo tim"
> >> JBoss Admin Command-line Interface
> >> JBOSS_HOME:
> >> /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
> >> JBoss AS release: <connect to the controller and re-run the
> >> version command to see the release info>
> >> JAVA_HOME: null
> >> java.version: 1.8.0_45
> >> java.vm.vendor: Oracle Corporation
> >> java.vm.version: 25.45-b02
> >> os.name: Linux
> >> os.version: 4.1.6-200.fc22.x86_64
> >> JBoss Admin Command-line Interface
> >> JBOSS_HOME:
> >> /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
> >> JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
> >> JAVA_HOME: null
> >> java.version: 1.8.0_45
> >> java.vm.vendor: Oracle Corporation
> >> java.vm.version: 25.45-b02
> >> os.name: Linux
> >> os.version: 4.1.6-200.fc22.x86_64
> >> tim
> >>
> >> The new output, as it exists right now, contains the command and
> >> it's output. Like so:
> >>
> >> [joe at localhost Changed Output]$
> >> ./wildfly-cli-2.0.0.CR1-SNAPSHOT-client-new.jar
> >> --commands=version,connect,version,"echo tim"
> >> WARN: can't find jboss-cli.xml. Using default configuration
> >> values.
> >> version
> >> JBoss Admin Command-line Interface
> >> JBOSS_HOME: null
> >> JBoss AS release: <connect to the controller and re-run the
> >> version command to see the release info>
> >> JAVA_HOME: null
> >> java.version: 1.8.0_45
> >> java.vm.vendor: Oracle Corporation
> >> java.vm.version: 25.45-b02
> >> os.name: Linux
> >> os.version: 4.1.6-200.fc22.x86_64
> >> connect
> >> Warning! The CLI is running in a non-modular environment and
> >> cannot load commands from management extensions.
> >> version
> >> JBoss Admin Command-line Interface
> >> JBOSS_HOME: null
> >> JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
> >> JAVA_HOME: null
> >> java.version: 1.8.0_45
> >> java.vm.vendor: Oracle Corporation
> >> java.vm.version: 25.45-b02
> >> os.name: Linux
> >> os.version: 4.1.6-200.fc22.x86_64
> >> echo tim
> >> tim
> >>
> >> 'version', 'connect', 'version', and 'echo tim' lines are now in
> >> the output, along with some information messages. I think this
> >> makes the output more useful, since the user can see which
> >> command was entered before the output or possible error occurs.
> >> It shouldn't have an impact on existing scripts, because the
> >> output still contains the expected output from any command and
> >> still ends with the last command output, so if someone is doing
> >> string analysis I wouldn't expect it to fail.
> >>
> >> I'd actually prefer to extend this change and add the command
> >> prompts into the output as well. Which would look like this:
> >>
> >> [joe at localhost bin]$ ./jboss-cli.sh --commands=version,"alias
> >> v=version",connect,v,"echo tim"
> >> [disconnected /] version
> >> JBoss Admin Command-line Interface
> >> JBOSS_HOME:
> >> /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
> >> JBoss AS release: <connect to the controller and re-run the
> >> version command to see the release info>
> >> JAVA_HOME: null
> >> java.version: 1.8.0_45
> >> java.vm.vendor: Oracle Corporation
> >> java.vm.version: 25.45-b02
> >> os.name: Linux
> >> os.version: 4.1.6-200.fc22.x86_64
> >> [disconnected /] alias v=version
> >> [disconnected /] connect
> >> [standalone at localhost:9990 /] v
> >> JBoss Admin Command-line Interface
> >> JBOSS_HOME:
> >> /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
> >> JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
> >> JAVA_HOME: null
> >> java.version: 1.8.0_45
> >> java.vm.vendor: Oracle Corporation
> >> java.vm.version: 25.45-b02
> >> os.name: Linux
> >> os.version: 4.1.6-200.fc22.x86_64
> >> [standalone at localhost:9990 /] echo tim
> >> tim
> >> [standalone at localhost:9990 /]
> >>
> >> This, to me, adds more information to the output making it more
> >> useful. I like the idea of the non-interactive mode imitating the
> >> interactive mode closely and essentially pretending to be a user,
> >> and this output is almost identical to a user entering these
> >> commands one at a time. It does, however, modify the end of the
> >> output stream which could break analysis scripts. A contains
> >> would be fine, but an ends-with would be broken because of the
> >> last prompt.
> >>
> >> Normal interactive mode output is unchanged. This will only effect
> >> '--file=' and '--commands=' output.
> >>
> >> Thoughts?
> >>
> >> Joe Wertz
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 


More information about the wildfly-dev mailing list