Service Providers are not properly propagated to children

[LexManos]

The last argument to defineModules is a function that looks up a module, and it's associated class loader.
This should return the correct classloader for that specific module which is required to trigger bindToLayer, which is required for the service catalog.

Psudo of what the function should be:
f -> newConf.modules.contains(d) ? classLoader : parent.stream().findFirst(l -> l.contains(f)).map(Layer::getClassLoader).orElse(classLoader)
This causes service loaders for things like SLF4J to fail if they are first loaded from the MC context, which, in 1.18.2 they are.

[ichttt]

I tried to implement it in the way you described. Unfortunally, this did not work. This is because Module.java only calls the function for modules of that classloader, and not it's parents.
I currently also don't see any other way to get the log4j2 service info into the transforming class loader.

[cpw]

Hmmm. We probably need to assume control of log4j loading anyway.

[marchermans]

From testing myself, it looks like this is not directly possible with the current setup. As @ichttt already stated Module.java has a weird corner case here and I doubt we could modify its behavior enough to make it work. Optionally we could make the ServiceLoader use an adapted route through the classloader and combine all service specifications from the parent layers into one?