Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ConfigProperty#value always read as null #2

Open
nullbuilds opened this issue Sep 10, 2019 · 1 comment
Open

ConfigProperty#value always read as null #2

nullbuilds opened this issue Sep 10, 2019 · 1 comment

Comments

@nullbuilds
Copy link

Problem

The value field of ConfigProperty instances returned from methods such as ConfigurationControllerApi#readConfiguration(String) and ConfigurationControllerApi#getConfiguration() is always null.

For example, executing this Groovy script:

new ConfigurationControllerApi(client)
    .getData()
    .getProperties()
    .stream()
    .forEach{ println("${it.name}:${it.value}") }

will output:

auditassistant.enabled:null
auditassistant.auth.token:null
...
x509.enabled:null
x509.username.pattern:null

I have attached a full Groovy script which demonstrates this issue.

Proposed Solution

Looking at the generated code, it appears this issue is being caused by an erroneous enum in the ConfigProperty model of spec.json. The relevant JSON snippet being:

"ConfigProperty": {
  "properties": {
    "value": {
      "type": "string",
      "description": "Configuration property value.",
      "enum": [
        "Depends on property type. It can be number",
        "string",
        "URL",
        "email or value from values list."
      ]
    }
  }
}

The value field has an enum constraint which appears to contain a description rather than allowable values. Because of this, the value field of the ConfigProperty class is being generated as an enum rather than a String. Since value is an enum, the API client is parsing the value returned by SSC as null since it does not match any items in the enum.

Removing the enum constraint from the spec.json file should fix this; however, I'm assuming the spec file in this repo was generated by SSC so only fixing it here would mean this would continue to be a problem for anyone generating their own client from SSC. A fix probably needs to be made to SSC as well.

@akaryakina
Copy link
Member

Thanks a lot for your thorough investigation Charles. Will pass this over to the SSC team. We're planning to generate a new version of the client for every new spec.json that corresponds to the SSC release. The spec that's used in this repository is fairly old, a lot of bugs has been fixed since. We're planning to review the REST API in 21.2 due to SOAP deprecation, it's currently scheduled for Nov 2021.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants