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

Brian Stansberry (JIRA) issues at jboss.org
Mon Nov 14 14:10:00 EST 2016


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

Brian Stansberry commented on WFCORE-1983:
------------------------------------------

I'm not sure from the description what is getting sent to the server.

If it is:

{code}
{"mynumber"=>"9999"}
{code}

instead of: 

{code}
{"mynumber"=>9999}
{code}

then yes, the server will almost certainly deal with that kind of type conversion properly. The server knows the desired type of the field and will attempt simple conversion to move from what the client provides to what is specified.

> 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)


More information about the jboss-jira mailing list