Re: Should ClassLoader::getResouces return the same resource twice?
Note that you are actually loading the JARs twice which means that you might have two versions of the same classses loaded, not only of the resources. Is this intentional? I still don't know what you want to achieve with your class loader and module layer. Am 02.01.2021 um 21:06 schrieb Thiago Henrique Hupner: Yes, the parent loader locates two resources and it is used in the defineModulesWithOneLoader. So the behavior is the following: module-a.jar -> META-INF/web-fragment.xml module-b.jar -> META-INF/web-fragment.xml Creating a URLClassloader with these two jars and calling the getResources, it returns two URLs. If then I create a module for each jar, the contents of each module will be the same as the content found by the URLClassloader. Using that classloader as the parent in the defineModulesWithOneLoader gives the following behavior: Calling getResources with the loader created by the ModuleLayer, it will search the resources in all the modules of that layer (module.a and module.b), and then delegate to the parent (URLClassloader), which will find the same resources, thus, doubling the results. Now describing it make clear to me that is something not easy to fix, so by now, I worked around it by creating a ModuleReader that only find the ".class" files in the module and the other resources will be available by the parent, however, I don't know if this solution is the best. Em sáb., 2 de jan. de 2021 às 14:51, Alan Bateman escreveu: On 02/01/2021 12:59, Thiago Henrique Hupner 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. Which parent class loader are you specifying to defineModulesWithOneLoader? It it possible that it locates the resource in the two JAR files? -Alan
Re: Should ClassLoader::getResouces return the same resource twice?
Yes, the parent loader locates two resources and it is used in the defineModulesWithOneLoader. So the behavior is the following: module-a.jar -> META-INF/web-fragment.xml module-b.jar -> META-INF/web-fragment.xml Creating a URLClassloader with these two jars and calling the getResources, it returns two URLs. If then I create a module for each jar, the contents of each module will be the same as the content found by the URLClassloader. Using that classloader as the parent in the defineModulesWithOneLoader gives the following behavior: Calling getResources with the loader created by the ModuleLayer, it will search the resources in all the modules of that layer (module.a and module.b), and then delegate to the parent (URLClassloader), which will find the same resources, thus, doubling the results. Now describing it make clear to me that is something not easy to fix, so by now, I worked around it by creating a ModuleReader that only find the ".class" files in the module and the other resources will be available by the parent, however, I don't know if this solution is the best. Em sáb., 2 de jan. de 2021 às 14:51, Alan Bateman escreveu: > On 02/01/2021 12:59, Thiago Henrique Hupner 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. > > > Which parent class loader are you specifying to > defineModulesWithOneLoader? It it possible that it locates the resource > in the two JAR files? > > -Alan >
Re: Should ClassLoader::getResouces return the same resource twice?
On 02/01/2021 12:59, Thiago Henrique Hupner 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. Which parent class loader are you specifying to defineModulesWithOneLoader? It it possible that it locates the resource in the two JAR files? -Alan
Re: Should ClassLoader::getResouces return the same resource twice?
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 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 >> 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. >>
Re: Should ClassLoader::getResouces return the same resource twice?
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 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. >
