[jboss-jira] [JBoss JIRA] (WFCORE-1726) CLI support for response attachments

[Brian Stansberry (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13283900#comment-13283900 ] 

Brian Stansberry commented on WFCORE-1726:
------------------------------------------

The/subsystem=logging/log-file=*:read-attribute(name=stream) problem seems like a general one, outside of batches. The --file attribute points to a single file but that op returns multiple streams.

Perhaps that could just be a documented limitation. If an individual 'attachment' operation (by itself or in a batch) returns > 1 stream. we'll just save/display 1. Probably the first one encountered when reading the response for that step. Instead of doing a wildcard requests people can write scripts to read the children names and then iterate over the result to read the files.


> CLI support for response attachments
> ------------------------------------
>
>                 Key: WFCORE-1726
>                 URL: https://issues.jboss.org/browse/WFCORE-1726
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> CLI doesn't support the streams attached to a response. Incremental deployment support offers today the ability to read the content of a deployment. It would be interesting to operate it from the CLI. Some resource (such as the log file) expose some attributes as stream.
> The following operations are returning streams: 
> /subsystem=logging/log-file=server.log:read-attribute(name=stream)
> /subsystem=logging/log-file=server.log:read-resource(include-runtime)
> /deployment=toto:read-content(path=index.html)
> As we can see, streams can be located in attributes, as operation response, inside a resource.
> The CLI offers 2 way to approach the problem:
> 1) Extend the Low level operation support with a way to save/display attached streams. This would require some XML configuration and possibly UI workflow to prompt user for the right action. Making from stream to file path would be not ideal and far from being user friendly. The good side is tha tit would work in any case (batch, non batch). The XML configuration can be a bit complex and prompting user is not an ideal workflow.
> 2) Define a new high level command that would cope with any operation.
> Such command would look like:
> attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=/my/local/path/to/file
> attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream)
> -  No risk to impact existing scripts. This is a new feature, so people would have to update their scripts to add the command.
> - The challenge is located in mapping a Stream to a file name. The user provides the name he wants. Furthermore, in interactive mode, the user can use completion to complete this target file.
> - No more prompting, the user knows ahead of time what he wants to do.
> - Problem is that batch mode doesn't re-dispatch each step response to each input command. So some logic should be needed to properly handle streams in batch.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)