When calling io.vertx.ext.web.handler.ErrorHandler.create(vertx), it could fail.
The reason is down to io.vertxc.core.file.impl.FileResolverImpl.resolveFile, when it try to track to parent folder to load file, the classloader could return wrong path.
eg. when input /META-INF/abc/def, the programme will first call classLoader.getResource("/META-INF/abc/def"), the result would be fine, because the input is specific enough, and then it will get one level up to call classLoader.getResource("/META-INF/abc"), it is still ok, as the abc is not everywhere. But when it calls classLoader.getResource("/META-INF"), thing will go wrong. One bad result is, it will return a random url end with .Jar or .Zip and get it content, although this is not the intention of the author. the worse result is, the classLoader returns Url not end with .Jar or .Zip, then the programme will throw error, because in the method of unpackUrlResource, it makes an assumption that, the Url must end with .Jar or .Zip, but in reality, it is not.
Version
4.4.3
Context
I encountered an exception which looks suspicious while ...
Do you have a reproducer?
No, I am not very familar on the inner mechanism of classloader, so don't know how to force the error to reproduce in another machine.
Extra
Anything that can be relevant such as OS version, JVM version
Questions
When calling io.vertx.ext.web.handler.ErrorHandler.create(vertx), it could fail. The reason is down to io.vertxc.core.file.impl.FileResolverImpl.resolveFile, when it try to track to parent folder to load file, the classloader could return wrong path.
eg. when input /META-INF/abc/def, the programme will first call classLoader.getResource("/META-INF/abc/def"), the result would be fine, because the input is specific enough, and then it will get one level up to call classLoader.getResource("/META-INF/abc"), it is still ok, as the abc is not everywhere. But when it calls classLoader.getResource("/META-INF"), thing will go wrong. One bad result is, it will return a random url end with .Jar or .Zip and get it content, although this is not the intention of the author. the worse result is, the classLoader returns Url not end with .Jar or .Zip, then the programme will throw error, because in the method of unpackUrlResource, it makes an assumption that, the Url must end with .Jar or .Zip, but in reality, it is not.
Version
4.4.3
Context
I encountered an exception which looks suspicious while ...
Do you have a reproducer?
No, I am not very familar on the inner mechanism of classloader, so don't know how to force the error to reproduce in another machine.
Extra