As an aside, creating a FileSystem is not an onerous task. https://stackoverflow.com/questions/22966176/creating-a-custom-filesystem-implementation-in-java
Cheers, — Jim 📱 > On Jan 2, 2021, at 8:59 AM, Thiago Henrique Hupner <thi...@gmail.com> wrote: > > I guess a little context can make more things clear: > The servlet spec requires that all jars from WEB-INF/lib > be available to the same classloader. > The resource, in particular, is "META-INF/web-fragment.xml" > Each jar can contain its own. So, using getResources make sense > in order of parsing each. However, what is happening is if I have two JARs > each with its own META-INF/web-fragment.xml, using the ModuleReader > it is returning four resources, so it parses more than it should and it > fails > to parse the same resource twice. > > I'll have a try only exposing the ".class" files in the ModuleReader, > so the Loader will be able to create the classes and it will read the > resources > from the classloader. > > I'm using my own implementations of the ModuleReader, ModuleFinder > and ModuleDescriptor because all of our resources are in memory I wasn't > able to > use the ModuleFinder.of() because it requires a filesystem. > >> Em sáb., 2 de jan. de 2021 às 04:07, Alan Bateman <alan.bate...@oracle.com> >> escreveu: >> >>> On 02/01/2021 03:21, Thiago Henrique Hupner wrote: >>> : >>> >>> I've created a simple example of what is occurring [1]. >>> I know there are behavior specific for getting a class if it is in a >> module, >>> but I don't know if this may be a bug in the resource loading mechanism. >>> In the example, the returned values are different to illustrate, but in >> my >>> case, it >>> returns two exact URLs for the same resource as the source for the module >>> reader >>> and the classloader is the same. >> The behavior you observe with the example is correct. >> ClassLoader.getResources locates the resource by searching the lass >> loader delegation chain and in the example there are two "foo" >> resources. The resource in module fake.module is located because it is >> an automatic module that opens all its packages unconditionally. The >> second resource is located by searching the parent class loader, a >> URLClassLoader in the example that also locates "foo". Which "foo" did >> you expect to locate? If code in fake.module just wants to locate the >> resource in its own module then it should use getResource rather than >> getResources. >> >> -Alan. >>
