jdegre / 5GC_APIs

RESTful APIs of main Network Functions in the 3GPP 5G Core Network
562 stars 249 forks source link

NullPointerException when generating TS29598_Nudsf_DataRepository as go-gin-server #46

Open DonRichie opened 2 years ago

DonRichie commented 2 years ago

Hello,

I am trying to generate server boilerplate code of the TS29598_Nudsf_DataRepository.yaml. Unfortunately I get a NullPointerException when doing so.

I want to generate as go-gin-server, but python-flask did produce the same error. Generating the TS29598_Nudsf_Timer.yaml works, but the DataRepostory doesn't.

Does someone know why this Error happens and is able to fix it?

Command:

openapi-generator-cli generate -g go-server --additional-properties=prependFormOrBodyParameters=true -o out -i TS29598_Nudsf_DataRepository.yaml

Error:

Exception: null
    at org.openapitools.codegen.DefaultGenerator.processOperation(DefaultGenerator.java:1163)
    at org.openapitools.codegen.DefaultGenerator.processPaths(DefaultGenerator.java:1054)
    at org.openapitools.codegen.DefaultGenerator.generateApis(DefaultGenerator.java:549)
    at org.openapitools.codegen.DefaultGenerator.generate(DefaultGenerator.java:891)
    at org.openapitools.codegen.cmd.Generate.execute(Generate.java:441)
    at org.openapitools.codegen.cmd.OpenApiGeneratorCommand.run(OpenApiGeneratorCommand.java:32)
    at org.openapitools.codegen.OpenAPIGenerator.main(OpenAPIGenerator.java:66)
Caused by: java.lang.NullPointerException
    at org.openapitools.codegen.DefaultCodegen.getContent(DefaultCodegen.java:6743)
    at org.openapitools.codegen.DefaultCodegen.fromOperation(DefaultCodegen.java:4006)
    at org.openapitools.codegen.DefaultGenerator.processOperation(DefaultGenerator.java:1131)
    ... 6 more
DonRichie commented 2 years ago

I believe the responses are the problem:

      responses:
        '200' : #result ok
          $ref: '#/components/responses/RecordBody'

If I swap the above lines in a limited example with a another schema, for example like this:

      responses:
        '200':
          description: Successful case. Response contains result of the search.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RecordSearchResult'

Then it works.

DonRichie commented 2 years ago

If I further swap

$ref: '#/components/responses/RecordBody'

with

$ref: '#/components/schemas/RecordBody'

It works. But only in my limited example. Not the full spec.

Please excuse my stumbling forward.

jdegre commented 2 years ago

hi @DonRichie; thanks for reporting the issue. from what I can see in the API definition, it seems that it is correct, and if you load the API with, say, with Swagger Editor or Swagger UI, they correctly render the response payload of the 200 OK response message, for the resource path: /{realmId}/{storageId}/records/{recordId}

the "swaps" you have done above, are not really valid, since you cannot simply replace $ref: '#/components/responses/RecordBody' with $ref: '#/components/schemas/RecordBody'

the former is a reference to an entire re-usable response component, while the latter is simply a reference to a given schema component, and both are entirely different. the reusable response component is defined as:

      content:
        multipart/mixed:
          schema:
            $ref: '#/components/schemas/Record'
          encoding:
              meta: # The meta part shall be the first part and is mandatory but can be empty.
                contentType: application/json
                headers:
                  Content-Id: # The meta part is identified by the 'meta' Content-Id header.
                    schema:
                      type: string
                    required: true
              blocks: # Zero or more block parts may follow the meta part
                contentType: '*/*' # Block parts can be of any type.
                headers:
                  Content-Id: # Block identifier is defined by the Content-Id header.
                    schema:
                      type: string
                    required: true
                  Content-Transfer-Encoding:
                    schema:
                      type: string
                    required: true
      headers:
        Cache-Control:
          $ref: '#/components/headers/Cache-Control'
        ETag:
          $ref: '#/components/headers/ETag'
        Last-Modified:
          $ref: '#/components/headers/Last-Modified'

so, it seems to me that openpi-generator does not handle well any of those definitions above.

maybe one way of narrowing-down the issue could be to replace $ref: '#/components/responses/RecordBody' in your test API, with the block I quoted above (the entire response message definition), and then, try to remove/change parts of it until you succeed with the code generation. at least this might indicate which part of such response definition is the "offending" part for openapi-generator.