[jboss-jira] [JBoss JIRA] (WFCORE-1726) CLI support for response attachments
[
https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi...
]
Brian Stansberry commented on WFCORE-1726:
------------------------------------------
[~jdenise] [~ehugonnet] In an earlier comment here and in the description of WFCORE-1741 I
described the requirements for providing the uuid in the result part of the response. This
comment here is a bit of a theoretical question since for the concrete deployment content
use case we are working the way the server will provide the file size for deployment
content is via the browse-content op and not read-content. But if Claudio hadn't
proposed that better way I had suggested including the file size in a complex result
object for read-content. If we had done that, or have some future case where we need to,
this bit I wrote in the description is wrong:
"2) If the thing providing the stream is a custom operation like :read-content, the
result value in the response must be the uuid of the stream."
Better would be:
2) If the thing providing the stream is a custom operation like :read-content, the result
value in the response must be the uuid of the stream or a complex result object one of
whose fields is the uuid of the stream."
Does that language work for you, Jeff?
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)