When used in a Quarkus project in dev mode, reading spec from a resource url fails because of differing classloaders #1968
Comments
mimkorn
pushed a commit
to mimkorn/swagger-parser
that referenced
this issue
Aug 29, 2023
This commit adds a fallback to `Thread.currentThread().getContextClassLoader().getResourceAsStream(file)` in the `ClasspathHelper` class. Previously, if the `ClasspathHelper.class.getResourceAsStream(file)` and `ClassLoader.getSystemResourceAsStream(file)` methods returned `null`, no further attempts were made to load the resource, which caused issues in Quarkus applications in dev mode. This commit adds an additional fallback to `Thread.currentThread().getContextClassLoader().getResourceAsStream(file)` to improve compatibility with the Quarkus class loading model. Related Issue: swagger-api#1968
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi!
In our quarkus project we call
OpenApiInteractionValidator.createForSpecificationUrl("/META-INF/openapi.yaml")...however, deep down inio.swagger.v3.parser.util.ClasspathHelperthere's a callClasspathHelper.class.getResourceAsStream(file);which gives a null InputStream. However, when debugging on that step and running withThread.currentThread().getContextClassLoader();instead, the file is found. I checked the two class loaders and they are different:In Quarkus documentation
Current impact is that debugging the application is unavailable, if code execution needs to use this part of your library.
Can we request a change in this library on how the classloader is picked, to make it compatible with Quarkus? Specifically, can we add another if (inputStream == null) and another option like:
Thread.currentThread().getContextClassLoader().getResourceAsStream(file)?Are there any concerns with making this change or any other preferred solutions?
Thank you for your consideration.
The text was updated successfully, but these errors were encountered: