[JBoss JIRA] (WFLY-7021) jdr.sh script should have better help message
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7021?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev moved JBEAP-5797 to WFLY-7021:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7021 (was: JBEAP-5797)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JDR
(was: JDR)
Affects Version/s: 10.1.0.Final
(was: 7.1.0.DR3)
> jdr.sh script should have better help message
> ---------------------------------------------
>
> Key: WFLY-7021
> URL: https://issues.jboss.org/browse/WFLY-7021
> Project: WildFly
> Issue Type: Bug
> Components: JDR
> Affects Versions: 10.1.0.Final
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
>
> jdr.sh script should have better help message. There is no general description about this script. There is only list of attributes.
> {code:bash}
> ./jdr.sh -h
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1746) Update the browse-content operation to return more information about the content
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1746?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reassigned WFCORE-1746:
-----------------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
> Update the browse-content operation to return more information about the content
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1746
> URL: https://issues.jboss.org/browse/WFCORE-1746
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha5
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> Currently the browse-content operation returns a list of String which defines the content file hierarchy. Instead it should return a list of complex type with at least the following attributes : a relative-path (aka the String currently returned), a boolean to indicate if it is a file or a folder, the file size (if it is a file, we won't compute the folder size).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1741) read-content operation does not return the uuid of the stream as the operation result
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1741?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1741:
-------------------------------------
Description:
See the tail end of the discussion on WFCORE-1726.
The rules around streams in responses are:
1) If the thing providing the stream is an attribute, the attribute value set by the read OperationStepHandler must be the uuid of the stream.
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.
Metadata about streams is propagated to the client using a response-header. But since a particular request can result in more than one attached stream, the normal non-response-header part of the result for a step must provide the uuid of the stream set by that step. This allows the client to correlate the various streams with the steps that provided them.
was:
See the tail end of the discussion on WFCORE-1726.
The rules around streams in responses are:
1) If the thing providing the stream is an attribute, the attribute value set by the read OperationStepHandler must be the uuid of the stream.
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.
Metadata about streams is propagated to the client using a response-header. But since a particular request can result in more than one attached stream, the normal non-response-header part of the result for a step must provide the uuid of the stream set by that step. This allows the client to correlate the various streams with the steps that provided them.
> read-content operation does not return the uuid of the stream as the operation result
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-1741
> URL: https://issues.jboss.org/browse/WFCORE-1741
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 3.0.0.Alpha6
>
>
> See the tail end of the discussion on WFCORE-1726.
> The rules around streams in responses are:
> 1) If the thing providing the stream is an attribute, the attribute value set by the read OperationStepHandler must be the uuid of the stream.
> 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.
> Metadata about streams is propagated to the client using a response-header. But since a particular request can result in more than one attached stream, the normal non-response-header part of the result for a step must provide the uuid of the stream set by that step. This allows the client to correlate the various streams with the steps that provided them.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1726) CLI support for response attachments
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1726:
----------------------------------------------
I read your earlier sentence as "can be somewhere in the response". I am scanning the result for uuid. I am searching in simple String, complex type and list, so should be just fine.
> 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)
9 years, 3 months
[JBoss JIRA] (WFCORE-1746) Update the browse-content operation to return more information about the content
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1746?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFCORE-1746:
-----------------------------------
Summary: Update the browse-content operation to return more information about the content (was: Update the browse-content operation to return more informations about the content)
> Update the browse-content operation to return more information about the content
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1746
> URL: https://issues.jboss.org/browse/WFCORE-1746
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha5
> Reporter: ehsavoie Hugonnet
> Assignee: Brian Stansberry
>
> Currently the browse-content operation returns a list of String which defines the content file hierarchy. Instead it should return a list of complex type with at least the following attributes : a relative-path (aka the String currently returned), a boolean to indicate if it is a file or a folder, the file size (if it is a file, we won't compute the folder size).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1726) CLI support for response attachments
by Brian Stansberry (JIRA)
[ 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)
9 years, 3 months
[JBoss JIRA] (WFLY-5892) JGroups throws UnknownHostException on processing IPv6 zone interface id with a subinterface
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5892?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-5892:
----------------------------------------
FWIW, here's a bit of argument that this is a VM bug that I did on a similar issue, WFCORE-934. In that case it was just affecting a test case so we were willing to hack the test to not execute the problem test if the relevant NetworkInterface is virtual and thus made the problem go away. But production code is a different beast. My comment on the other issue:
"
Looks like a JVM problem then. InetAddress.getByName("fe80:0:0:0:8:20ff:fe6d:eab0%net0:2") is not behaving in accordance with javadoc. It is throwing UnknownHostException when it should not. For a literal IPv6 address string that represents a link-local or site-local it should only check the validity of the address format. The format is valid, as described at https://docs.oracle.com/javase/8/docs/api/java/net/Inet6Address.html#scoped which is linked in the InetAddress.getByName javadoc.
For an IPv6 literal address string with a scope_id appended, UnknownHostException should only be thrown if the address isn't a site-local or link-local address.
This test passes in the community CI runs: http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WildFlyCore&...
There have been failures in the past. I haven't examined them all, but it looks like the failures were due to incorrectly testing global IPv6 addresses, which my patch fixed.
What's happening here is for an InetAddress 'address' obtained from inspecting the addresses available on the system, InetAddress.getByName(address.getHostAddress()) is throwing an UnknownHostException. That's clearly wrong.
"
The test change is here: https://github.com/wildfly/wildfly-core/pull/1415/files
> JGroups throws UnknownHostException on processing IPv6 zone interface id with a subinterface
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5892
> URL: https://issues.jboss.org/browse/WFLY-5892
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Environment: Solaris 11 Sparc JDK8, IPv6
> Reporter: Michal Karm Babacek
> Assignee: Bela Ban
> Priority: Critical
> Attachments: tcp.xml
>
>
> JGroups pick up IPv6 zone id index and it fails at translating it into an interface name:
> h3. Address
> * address used {{2620:52:0:105f:0:0:ffff:188%net0:2}}
> * {{Caused by: java.net.UnknownHostException: no such interface net0:2}}
> h3. Configuration
> {code}
> <interfaces>
> <interface name="management">
> <inet-address value="2620:52:0:105f::ffff:188"/>
> </interface>
> <interface name="public">
> <inet-address value="2620:52:0:105f::ffff:188"/>
> </interface>
> </interfaces>
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> <socket-binding name="https" port="${jboss.https.port:8443}"/>
> <socket-binding name="jgroups-mping" port="0" multicast-address="ff02::12" multicast-port="45700"/>
> <socket-binding name="jgroups-tcp" port="7600"/>
> <socket-binding name="jgroups-tcp-fd" port="57600"/>
> <socket-binding name="jgroups-udp" port="55200" multicast-address="ff02::12" multicast-port="45688"/>
> <socket-binding name="jgroups-udp-fd" port="54200"/>
> <socket-binding name="modcluster" port="0" multicast-address="ff02::a" multicast-port="32983"/>
> <socket-binding name="txn-recovery-environment" port="4712"/>
> <socket-binding name="txn-status-manager" port="4713"/>
> <outbound-socket-binding name="mail-smtp">
> <remote-destination host="localhost" port="25"/>
> </outbound-socket-binding>
> </socket-binding-group>
> {code}
> h3. Exception
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.jgroups.channel.ee: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> at org.wildfly.clustering.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:80)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:640)
> at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:98)
> at org.wildfly.clustering.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:78)
> ... 5 more
> Caused by: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1154)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:445)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:853)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:95)
> at org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:92)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> ... 7 more
> Caused by: java.lang.Exception: Conversion of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1148)
> ... 17 more
> Caused by: java.net.UnknownHostException: no such interface net0:2
> at java.net.Inet6Address.initstr(Inet6Address.java:487)
> at java.net.Inet6Address.<init>(Inet6Address.java:408)
> at java.net.InetAddress.getAllByName(InetAddress.java:1181)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at java.net.InetAddress.getByName(InetAddress.java:1076)
> at org.jgroups.conf.PropertyConverters$Default.convert(PropertyConverters.java:288)
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:81)
> ... 18 more
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "ee")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.jgroups.channel.ee" => "org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> Caused by: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> Caused by: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> Caused by: java.lang.Exception: Conversion of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 failed
> Caused by: java.net.UnknownHostException: no such interface net0:2"}}
> {code}
> h3. Interfaces on the Solaris 11 box
> See my undermentioned example:
> {code}
> [mbabacek@dev33 ~]$ groovy https://gist.githubusercontent.com/Karm/ec21b42b59f8889f976f/raw/951f01c6...
> Iface Display name: net4
> Iface Name: net4
> Iface Display name: net0
> Iface Name: net0
> Subiface Display name: net0:7
> Subiface Name: net0:7
> Subiface Display name: net0:6
> Subiface Name: net0:6
> Subiface Display name: net0:5
> Subiface Name: net0:5
> Subiface Display name: net0:4
> Subiface Name: net0:4
> Subiface Display name: net0:3
> Subiface Name: net0:3
> Subiface Display name: net0:2
> Subiface Name: net0:2
> Subiface Display name: net0:1
> Subiface Name: net0:1
> Iface Display name: lo0
> Iface Name: lo0
> {code}
> WDYT? Why should JGroups even try to do that?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1743) Unable to force CLI to execute a low level command
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1743?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1743:
------------------------------------------
Thanks for the explanation. I like the idea of ignoring the error, at least if "validate-operation-requests" is set to false. That's a bit of a misuse of "validate-operation-requests" since this isn't actually validation. So reusing that flag to control both things is a tiny bit ugly. But to a degree it really is validation, since you'll go ahead and grab the description and that should only fail if the request is invalid.
> Unable to force CLI to execute a low level command
> --------------------------------------------------
>
> Key: WFCORE-1743
> URL: https://issues.jboss.org/browse/WFCORE-1743
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha5
> Reporter: Brian Stansberry
> Assignee: Alexey Loubyansky
> Fix For: 3.0.0.CR1
>
>
> I cannot get this operation to execute, even if I set validate-operation-requests to false in jboss-cli.xml:
> {code}
> [standalone@embedded /] /subsystem=datasources/bogus=*:read-resource-description
> Failed to get the list of the operation properties: "WFLYCTL0030: No resource definition is registered for address [
> ("subsystem" => "datasources"),
> ("bogus" => "*")
> ]"
> {code}
> It is important that the CLI allows users to send whatever low level ops they wish to the server if they turn off verification. The server validates requests itself, and in some cases can be coded to be lenient about things (e.g. to let previous 'wrong' things work.) We don't want the CLI to get in the way of that by doing client side validation that cannot be turned off.
> Problem seems to be this in the Util class:
> {code}
> public static ModelNode toOperationRequest(CommandContext ctx,
> ParsedCommandLine parsedLine, Attachments attachments)
> throws CommandFormatException {
> return toOperationRequest(ctx, parsedLine, attachments, true);
> }
> {code}
> That 'true' param results in the CLI trying to do a background read-operation-description and failing the op if unsuccessful.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1743) Unable to force CLI to execute a low level command
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1743?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky commented on WFCORE-1743:
-------------------------------------------
I see your point. The CLI, though, is not actually retrieving the description for validation purposes but to actually complete building the operation request since there are some usability features that require the description. Such as replacement of certain user-friendly parameter values with the values that actually should be sent. For example replacing file system paths with attached streams (user specifies file system paths as parameters while the CLI, according to the operation parameter descriptions, turns those into attachments).
I guess, in the CLI, in case the description could not be retrieved, instead of throwing an error, we could simply ignore it, do not replace anything and send the request as it was literally typed-in.
> Unable to force CLI to execute a low level command
> --------------------------------------------------
>
> Key: WFCORE-1743
> URL: https://issues.jboss.org/browse/WFCORE-1743
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha5
> Reporter: Brian Stansberry
> Assignee: Alexey Loubyansky
> Fix For: 3.0.0.CR1
>
>
> I cannot get this operation to execute, even if I set validate-operation-requests to false in jboss-cli.xml:
> {code}
> [standalone@embedded /] /subsystem=datasources/bogus=*:read-resource-description
> Failed to get the list of the operation properties: "WFLYCTL0030: No resource definition is registered for address [
> ("subsystem" => "datasources"),
> ("bogus" => "*")
> ]"
> {code}
> It is important that the CLI allows users to send whatever low level ops they wish to the server if they turn off verification. The server validates requests itself, and in some cases can be coded to be lenient about things (e.g. to let previous 'wrong' things work.) We don't want the CLI to get in the way of that by doing client side validation that cannot be turned off.
> Problem seems to be this in the Util class:
> {code}
> public static ModelNode toOperationRequest(CommandContext ctx,
> ParsedCommandLine parsedLine, Attachments attachments)
> throws CommandFormatException {
> return toOperationRequest(ctx, parsedLine, attachments, true);
> }
> {code}
> That 'true' param results in the CLI trying to do a background read-operation-description and failing the op if unsuccessful.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1746) Update the browse-content operation to return more informations about the content
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-1746:
-----------------------------------------
Summary: Update the browse-content operation to return more informations about the content
Key: WFCORE-1746
URL: https://issues.jboss.org/browse/WFCORE-1746
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Affects Versions: 3.0.0.Alpha5
Reporter: ehsavoie Hugonnet
Assignee: Brian Stansberry
Currently the browse-content operation returns a list of String which defines the content file hierarchy. Instead it should return a list of complex type with at least the following attributes : a relative-path (aka the String currently returned), a boolean to indicate if it is a file or a folder, the file size (if it is a file, we won't compute the folder size).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months