To Jason: many thanks for the link - that spares me for extra trouble :)
To Brian: yes - there are for sure other people that are in the 'dark' as me and any open discussion is always productive. (+)
I'll go ahead with Jason link and since I will be 'mean' ;) - I will create one ModuleExtension and three Modules #1, #2, #3 with the following setup:
ModuleExtension loads --> ServiceLoadApiFromModule#1 --> executes the impl from Module#1
ServiceLoadApiFromModule#1 impl loads --> ServiceLoadApiFromModule#2 --> executes the impl from Module #2 see next (so Module#1 needs to have TCCL visibility on Module#2 )
ServiceLoadApiFromModule#2 --> ServiceLoadApiFromModule#3 (so Module#2 needs to have TCCL visibility on Module#3) --> executes the impl from Module #3 --> test stops
In a genric way, once in a Module, the Module should have visibility on all other Modules that were added as dependecies in the ModuleExtension, to cover more complex stuff.
ModuleExtension -> ServiceLoadApiFromModule#1 loader can happen with 2 arguments since it comes from ModuleExtension (it can use even the jboss-module service loader) but the remaining:
ServiceLoadApiFromModule#2,#3 - shall happen only with 1 argument since it is comming from Module and shall use the java.util.ServiceLoader.load().
Should the below achievable via module.xml setup as discussed ? If not, what would be the a code snapshot on classpath settings.
Brian Stansberry wrote:
The classloader for the ModuleExtension module, which in 7.0.2 will be the TCCL, may not have visibility to classes in Module#2. That's the nature of modular classloading -- the intent is to provide proper isolation, and not to expose everything to everybody. So if you think Module#1 is going to be relying on the TCCL having visibility to everything Module#1 depends on, then you should set the TCCL to a classloader that should have that visibility. Most likely that is Module#1's classloader.
Is this sound correct to you ?
BR,
Dan S.