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 resourceAndBind, but I'm getting > "Provider foo.bar not found" > > There is some trick to get a class from an upper layer to bind to the > a class in the boot layer? > > Thanks! > > Em seg., 4 de jan. de 2021 às 09:41, Johannes Spangenberg < > johannes.spangenb...@hotmail.de> escreveu: > >> 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 >> > classloader, >> > and have some important information stored in it, so by removing the >> > jars from the classloader >> > all applications would stop working. >> >> If you really need this information as part of the class loader, I fear >> you need to create custom class loaders for your modules together with >> ModuleLayer.defineModules [1] instead of >> ModuleLayer.defineModulesWithOneLoader. The class loader for >> ModuleLayer.defineModulesWithOneLoader is not public. I guess you would >> need to reimplement it. Maybe you can find other locations to store the >> information. >> >> [1] >> >> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/ModuleLayer.html#defineModules(java.lang.module.Configuration,java.util.List,java.util.function.Function) >> >> Am 04.01.2021 um 12:38 schrieb Thiago Henrique Hupner: >> > 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 have a look at the application classloader >> > and update my current classloader to be able to do the bidirectional >> > delegation. Do you have any recommendations about where to look? >> > >> > Thanks! >> > >> > Em seg., 4 de jan. de 2021 às 05:48, Alan Bateman < >> alan.bate...@oracle.com> >> > escreveu: >> > >> >> 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 you >> want >> >> to "move" the well behaved components to a module path, leaving the >> >> remaining the components that can't work as automatic modules on the >> >> class path. It's equivalent to specifying both a module path and class >> >> path to the java command line launcher. You also mention that you have >> >> to use a custom class loader. If that class loader were updated to >> >> support modules and load classes into its unnamed module then you >> should >> >> be able to get this to work. This is very advanced territory and would >> >> be approximately equivalent to the application class loader in the JDK >> >> where it supports both modules and the class path. I don't think your >> >> current approach of using a URLClassLoader as a parent will work as it >> >> doesn't support the bidirectional delegation that would be need to get >> >> this to work. >> >> >> >> -Alan. >> >> >> >
