When used in a Quarkus project in dev mode, reading spec from a resource url fails because of differing classloaders

Hi!

In our quarkus project we call OpenApiInteractionValidator.createForSpecificationUrl("/META-INF/openapi.yaml")... however, deep down in io.swagger.v3.parser.util.ClasspathHelper there's a call ClasspathHelper.class.getResourceAsStream(file); which gives a null InputStream. However, when debugging on that step and running with Thread.currentThread().getContextClassLoader(); instead, the file is found. I checked the two class loaders and they are different:

• Quarkus Base Runtime ClassLoader: DEV
• Quarkus Runtime ClassLoader: DEV restart no:0

In Quarkus documentation

The recommended approach is to get it by calling the Thread.currentThread().getContextClassLoader() method

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.

Start by locating io.swagger.v3.parser.util.ClasspathHelper and the getResourceAsStream call used by OpenApiInteractionValidator.createForSpecificationUrl. Reproduce the lookup in Quarkus dev mode, compare the class loader behaviors described in the issue, and verify that /META-INF/openapi.yaml can be read successfully without breaking existing resource loading.