[Java][Fix #3310] Respect discriminator case for @JsonTypeInfo

[jburgess]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

Description of the PR

Prior to this fix the generated @JsonTypeInfo property was converted to camel case. This fix uses the raw discriminator value specified in the API schema for Java server and client code generation.

See #3310 for more details

@bbdouglas (2017/07) @sreeshas (2017/08) @jfiala (2017/08) @lukoyanov (2017/09) @cbornet (2017/09) @jeff9finger (2018/01) @karismann (2019/03) @Zomzog (2019/04)

[jeff9finger]

Ensure that x-discriminator-value: vendor extension still works with this change.

[jburgess]

Ensure that x-discriminator-value: vendor extension still works with this change.

@jeff9finger It looks like x-discriminator-value suffers a similar case manipulation for @JsonSubTypes.Type (OAS 3.0) that this PR addresses for discriminator. Which OAS version are you using/tested with?:

given an OAS 3.0 specification containing:

    BaseObj:
      type: object
      discriminator: 
        propertyName: object_type
      required:
        - id
        - object_type
      properties:
        id:
          type: integer
          format: int64
        object_type:
          type: string
          readOnly: true

    SubObj:
      x-discriminator-value: sub-obj
      allOf:
        - $ref: '#/components/schemas/BaseObj'
        - type: object
          discriminator:
            propertyName: sub_obj_type
          required:
            - sub_obj_type
          properties:
            sub_obj_type:
              $ref: '#/components/schemas/SubObjType'
            name:
              type: string

Codegen produces:

@javax.annotation.Generated(value = "org.openapitools.codegen.languages.JavaClientCodegen", date = "2019-07-09T14:42:33.020-04:00[America/New_York]")
@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "object_type", visible = true)
@JsonSubTypes({
  @JsonSubTypes.Type(value = SubObj.class, name = "SubObj"),
})

[jeff9finger]

My company is currently using OAS 2.0. But we will be moving to OAS 3.0 ASAP - hopefully this year. I just want to make sure that this feature will still work correctly with your fix in OAS 3.0.

According to your comment, it looks like it does indeed fix this issue when x-discriminator-value is used.

Thanks for the confirmation!

👍

[jburgess]

@jeff9finger I believe a similar fix will be needed for x-discriminator-value for OAS 3.X. Note the case change x-discriminator-value: sub-obj produced @JsonSubTypes.Type(value = SubObj.class, name = "SubObj").

sub-obj != SubObj

[jeff9finger]

Oops! I did not read your comment closely enough. Are you able to add your fix for the x-discriminator-value for OAS 3?

One issue to consider is what occurs when the model does not have a defined discriminator value. I assume that in this case, the model name will be used as it is now.

[jburgess]

I looked at the codegen for mappings and they follow a different pattern. I believe fixing the mapping should be under a different PR.

One issue to consider is what occurs when the model does not have a defined discriminator value. I assume that in this case, the model name will be used as it is now.

From my understanding the discriminator is required for polymorphism. Are you referring to the mapping and x-discriminator-value definitions which map an attribute value to an object? If so, I agree. The object should map to the object definition name in the event they are not present.

[jeff9finger]

I looked at the codegen for mappings and they follow a different pattern. I believe fixing the mapping should be under a different PR.

OK. Thanks for investigating that. I think that is the best way to handle it.

Are you referring to the mapping and x-discriminator-value definitions which map an attribute value to an object? If so, I agree. The object should map to the object definition name in the event they are not present.

Yes. We agree. :-)

[wing328]

I'll rename it to propertyBaseName in a separate PR to make the naming consistent with the baseName CodegenProperty and CodegenParameter.

[wing328]

Filed #4124

[wing328]

CI failures have been fixed in the master.

[wing328]

@jburgess thanks for the PR, which has been included in v4.2.0 release: https://twitter.com/oas_generator/status/1189824932345069569