Looks like the ModuleLayer.defineModules is the thing I needed.
With it, I can use my current classloader to load all the modules
and it can find the classes from both module and unnamed module.
Note that class loaders for modules behave differently then original
class loaders. For example
The trick is that now I'm using my classloader
to load the modules, I need to override the ClassLoader#findClass(String
module, String className)
So the service loader finds the classes successfully.
Em seg., 4 de jan. de 2021 às 10:51, Thiago Henrique Hupner <
thi...@gmail.com> escreveu:
>
Looks like the ModuleLayer.defineModules is the thing I needed.
With it, I can use my current classloader to load all the modules
and it can find the classes from both module and unnamed module.
However, I'm having some trouble with the ServiceLoader now,
In the configuration, I've called
The bidirectional delegation is an important point. Beside that, you
also mentioned that your custom class loader stores additional information.
Unfortunately, I cannot only remove the jars from my classloader and
delegate
to the classloader provided by the ModuleLayer because we use a custom
Yes, that's exactly it. Sorry for all the noise in the previous emails.
I'm not using a URLClassLoader in my application, I've only used it
as an example because it is very easy to override to return a specific
value (and not have to implement all the other methods).
So, I guess I will need to
On 03/01/2021 13:10, Thiago Henrique Hupner wrote:
:
I hope made it a little more clear. By now it is clear that it is loading
the same
resource twice because the same jar is in the classloader and in the module
layer
classloader.
If I read your mail correctly you've got a class path today and
Yes, that is intentional.
So I guess the correct behavior is to find the jars only via the
ModuleFinder,
and use the classloader only for nonmodular jars, is this right?
In the Servlet spec, it is allowed to have split packages, from the
WEB-INF/classes
and WEB-INF/lib/ jars, for instance, so it
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
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
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,
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:
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.
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
Hi!
I'm working to integrate the JPMS into our application server in a way that
the applications can run in a layer each, but I faced something strange:
our current behavior without layers,
calling ClassLoader::getResources in the classloader
provided by us, it will return a return "foo".
In the
14 matches
Mail list logo
