[jboss-jira] [JBoss JIRA] (WFCORE-1983) CLI type decision INT/STRING LONG/STRING

[Jean-Francois Denise (JIRA)]

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

Jean-Francois Denise edited comment on WFCORE-1983 at 11/16/16 8:30 AM:
------------------------------------------------------------------------

I have looked at the server side handling of arguments for the read-resource (ReadResourceHandler).
When the numbers or String are in range, aproper adaptation is made on the server side.
:read-resource(recursive-depth="9"), :read-resource(recursive-depth=9L), :read-resource(recursive-depth=9.4), are property converted from STRING/LONG/DOUBLE to INT.

With an out of range value (:read-resource(recursive-depth=999999999999)). The cli converts the out of range depth to STRING and send the request.

The conversion to INT fails and the exception is swallowed in ModelTypeValidator.matches.

The server side should keep a reference to the last thrown exception and throw that instead of the generic type mismatch.






was (Author: jdenise):
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)