[BUG] [codegen] external $ref in parameters not getting resolved #1976
Comments
|
👍 Thanks for opening this issue! The team will review the labels and make any necessary changes. |
|
+1 on this. I really wish I could use references 😭 |
|
From the stacktrace, it seems that the problem is located in Swagger-Parser library. Please have a look at how Swagger-Parser is parsing your file and try to produce a minimal example. Sample Java Snippet: OpenAPIParser openApiParser = new OpenAPIParser();
ParseOptions options = new ParseOptions();
options.setResolve(true);
options.setFlatten(true);
OpenAPI openAPI = openApiParser.readLocation(inputSpec, null, options).getOpenAPI();
String string = Yaml.mapper().writerWithDefaultPrettyPrinter().writeValueAsString(openAPI);
System.out.println(string);Maven coordinates of the dependency for your test project: <dependency>
<groupId>io.swagger.core.v3</groupId>
<artifactId>swagger-core</artifactId>
<version>2.0.6</version>
</dependency>Let me know if you need help. |
|
I've modified the petstore.yaml example to reproduce the issue. Original found here: https://github.com/OAI/OpenAPI-Specification/tree/master/examples/v3.0/petstore.yaml. |
|
As suggested, I wrote some code to directly parse the OpenAPI spec files from this location ( https://github.com/jdegre/5GC_APIs.git ), with the target being a locally corrected version of TS29514_Npcf_PolicyAuthorization.yaml. When using the swagger-parser directly, I was able to consume this yaml, including the external references successfully. The crude test program I wrote to try processing the same yaml files is attached as well, just run the jar and add an argument that is the qualified yaml file name. I've attached just the files yaml files I used below |
I found a mistake in these yaml files, they should be ignored. |
|
I have re-tested this with the v4.0.0-beta2 release and was able to process all of the models, so this was addressed somehow? |
|
My test is not working with the latest v4.0.0-beta2 release. Results in: In swagger-codegen I had to use |
|
I had the same issue with openapi-generator-maven-plugin version 3.3.4 and 5G API spec (namely, TS29510_Nnrf_NFManagement.yaml). So, upgrade of swagger-parser to 2.0.5 solved the problem: |
|
Can you retry with |
|
@jmini I have encountered similar issue, on v.4.0.0-beta3 it happens: Even though, validation command passes successfully.. |
|
Hi @jmini - it's still not working in v4.0.0-beta3 release. Results in: The test definition is available so you can run the same command to test it. Thanks! |
|
@jweisman Thank you for the feedback... Sorry for the delay. |
|
@jmini, this issue was resolved only in the last week in the swagger-parser repository. I think you have not published that yet... |
|
I have prepared PR #2775 to update Swagger-Parser |
|
@jmini - the spec I'm using is The offending line is: The referenced file exists in the same path. |
|
I have updated Swagger-Parser. |
|
For the impatient: To fix my problem, I've used https://github.com/APIDevTools/json-schema-ref-parser (after turning my main yaml spec into json) and de-referenced all the Then, I was able to generate the client code :) PSA: This is a hotfix and any code generated should be well tested. |
|
Hi @jmini - I downloaded the (now release) version of 4.0.0 and I'm getting the same behavior.
Note also that:
|
|
I have the same problem with multiple level of JSON references using only local files with version 4.0.0. I had to override the class on the classpath to be able to change this option. It should maybe be exposed in the plugin options in the future. |
|
With |
The problem with With this input: openapi: 3.0.1
info:
title: ping test
version: '1.0'
servers:
- url: 'http://localhost:9999/'
paths:
/ping:
get:
operationId: pingGet
responses:
'201':
description: OK
content:
'*/*':
schema:
$ref: "#/components/schemas/MainObj"
components:
schemas:
SomeObj:
type: object
properties:
id:
type: integer
format: int64
MainObj:
type: object
properties:
lorem:
$ref: "#/components/schemas/SomeObj"
ipsum:
type: stringThe output of Swagger-Parser is openapi: 3.0.1
info:
title: ping test
version: "1.0"
servers:
- url: http://localhost:9999/
paths:
/ping:
get:
operationId: pingGet
responses:
201:
description: OK
content:
'*/*':
schema:
type: object
properties:
lorem:
type: object
properties:
id:
type: integer
format: int64
ipsum:
type: string
components:
schemas:
SomeObj:
type: object
properties:
id:
type: integer
format: int64
MainObj:
type: object
properties:
lorem:
type: object
properties:
id:
type: integer
format: int64
ipsum:
type: stringIn the operation, there is no information anymore about the models defined in I did not try it, but my guess is that OpenAPI-Generator will generator other models than the one defined in I do not believe that this is what the users want. |
|
Hi @jmini - same with 4.0.3.
Out of curiosity- does this sample spec work for you? Perhaps it's something I'm doing wrong? |
|
Is there any update on this? I just tried with both version 4.2.2 and 4.2.3 and the schemas defined under components/schemas and referenced using $ref are not included in the generated HTML documentation. Thanks. |
|
Also having this issue, tried to make a replica case in |
|
I'm having the same problem when migrating an existent spec from version 2 to 3, and I would really like to avoid having to move all models defined in the common file to each spec file. |
|
If you scroll up a bit, I offered a hacky quick fix, which worked for me. |
|
thanks for the reminder @lacksfish here's a small node script that implements the idea, run with const $RefParser = require("@apidevtools/json-schema-ref-parser");
const fs = require('fs');
let args = process.argv.slice(2);
let rawdata = fs.readFileSync(args[0]);
let input = JSON.parse(rawdata);
$RefParser.dereference(input, (err, schema) => {
if (err) {
console.error(err);
}
else {
let data = JSON.stringify(schema, null, 2);
fs.writeFileSync(args[1], data);
}
}) |
|
What is the status of this issue? EDIT: From what I can see, the problem is that when resolving repeated refs, the parser uses the original base URL (the root) instead or resolving relative to the referencing document. Sorry, I'm ranting a bit here. I would think such a file resolution issue would be important enough to fix it before 20 months. I'm currently generating a JSON-schema for each tool that uses schema and falls apart for different reasons, I have sliced, slashed, splitted, merged and partially merged schema, I am patching output with regexes and I am now doing the same for each openapi tool I am using, because no single tool is able to understand any schema dialect and handle it correctly. I so miss the time when I could work with XSD. |
Description
When attempting to generate code from an OpenAPI document that included $ref , all of the references failed to be resolved and are included in files in the same directory. I've seen other's report this issue before, but it is supposed to be resolved in the version I tested with.
openapi-generator version
3.3.4
OpenAPI declaration file content or url
https://github.com/jdegre/5GC_APIs.git
Command line used for generation
% java -jar openapi-generator-cli.jar generate -i ./TS29514_Npcf_PolicyAuthorization.yaml -g java-vertx -o ./PCF/PolicyAuth
Steps to reproduce
Working in Ubuntu 16.04 ( if that matters ).
I followed the instructions here ( https://openapi-generator.tech/docs/installation ) and installed the JAR, to pull down the 3.3.4 version of the library. I cloned OpenAPI yaml specifications from this repo: https://github.com/jdegre/5GC_APIs.git
Tried to generate with this command:
% java -jar openapi-generator-cli.jar generate -i ./TS29514_Npcf_PolicyAuthorization.yaml -g java-vertx -o ./PCF/PolicyAuth
The output was as follows:
[main] WARN io.swagger.v3.parser.OpenAPIV3Parser - Exception while reading:
java.lang.NullPointerException: null
at io.swagger.v3.parser.ResolverCache.updateLocalRefs(ResolverCache.java:162)
at io.swagger.v3.parser.ResolverCache.loadRef(ResolverCache.java:152)
at io.swagger.v3.parser.processors.ExternalRefProcessor.processRefToExternalResponse(ExternalRefProcessor.java:205)
at io.swagger.v3.parser.processors.ResponseProcessor.processReferenceResponse(ResponseProcessor.java:76)
at io.swagger.v3.parser.processors.ResponseProcessor.processResponse(ResponseProcessor.java:38)
at io.swagger.v3.parser.processors.OperationProcessor.processOperation(OperationProcessor.java:56)
at io.swagger.v3.parser.processors.PathsProcessor.processPaths(PathsProcessor.java:83)
at io.swagger.v3.parser.OpenAPIResolver.resolve(OpenAPIResolver.java:49)
at io.swagger.v3.parser.OpenAPIV3Parser.readLocation(OpenAPIV3Parser.java:53)
at io.swagger.parser.OpenAPIParser.readLocation(OpenAPIParser.java:19)
at org.openapitools.codegen.config.CodegenConfigurator.toClientOptInput(CodegenConfigurator.java:552)
at org.openapitools.codegen.cmd.Generate.run(Generate.java:354)
at org.openapitools.codegen.OpenAPIGenerator.main(OpenAPIGenerator.java:62)
[main] WARN o.o.codegen.utils.ModelUtils - Failed to get the schema name: ./TS29571_CommonData.yaml#/components/schemas/RouteToLocation
[main] WARN o.o.codegen.utils.ModelUtils - Failed to get the schema name: ./TS29571_CommonData.yaml#/components/schemas/RouteToLocation
[main] WARN o.o.codegen.utils.ModelUtils - Failed to get the schema name: ./TS29571_CommonData.yaml#/components/schemas/PresenceInfo
[main] WARN o.o.codegen.utils.ModelUtils - Failed to get the schema name: ./TS29571_CommonData.yaml#/components/schemas/PresenceInfo
.
. LOTS more warnings like these, omitted to keep this concise
.
[main] WARN o.o.codegen.utils.ModelUtils - Failed to get the schema name: ./TS29571_CommonData.yaml#/components/responses/503
[main] WARN o.o.codegen.utils.ModelUtils - Failed to get the schema name: ./TS29571_CommonData.yaml#/components/responses/default
Exception in thread "main" org.openapitools.codegen.SpecValidationException: There were issues with the specification. The option can be disabled via validateSpec (Maven/Gradle) or --skip-validate-spec (CLI).
| Error count: 1, Warning count: 0
Errors:
-null
Related issues/PRs
This one seems very similar:
#455
Suggest a fix
The text was updated successfully, but these errors were encountered: