[
https://issues.jboss.org/browse/WFCORE-1983?page=com.atlassian.jira.plugi...
]
Jean-Francois Denise commented on WFCORE-1983:
----------------------------------------------
I have looked at the server side handling of arguments for the read-resource
(ReadResourceHandler).
The faulty operation is: :read-resource(recursive-depth=999999999999). The cli converts
the out of range depth to STRING and send the request.
The server handler validates each parameter and checks for the value type. The only valid
type for recursive-depth is INT. So the operation fails with "WFLYCTL0097: Wrong type
for 'recursive-depth'. Expected [INT] but was STRING".
Same occurs for list-add.index.
CLI type decision INT/STRING LONG/STRING
----------------------------------------
Key: WFCORE-1983
URL:
https://issues.jboss.org/browse/WFCORE-1983
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
It happens that the CLI does a custom parsing of the value in case ModelNode.fromString
fails (whatever the exception).
The issue is that the custom parsing doesn't follow the ModelNode parsing syntax and
parse everything as String. So the resulting ModelNode that is serialised and sent to the
server has been transformed.
I am surprised that we don't have more of such failures. For example, when numbers
are located inside custom complex structure such as: {mynumber=9999} that will be sent as
an OBJECT containing a STRING although the valid DMR syntax {"my
number"=>999} would be sent as an OBJECT containing an INT.
Some server side subsystems are smart enough to call into asXXX methods and not check the
type?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)