Hi,
The good news is that we are converging in ideas (+) . No frustration - yet ;)
The bad news is that somehow I do not get what I think I should get :0 . And what from design point of view sounds correct to me.
My example is a lot more complicated than I what I explained here. I do have a ModuleExtension that depends on a Module#1, then Module#1 dependes on Module#2 and few others for example, and Module#1, Module#2 do have exposed services.
If I have to 'customize' ModuleExtension to kistart Module#1 - then again I do not have an issue since it is jboss module specific. BUT and from here on we diverge in opinions .... looks like ;)
Module#1 does also a ServiceLoader.load(ServiceAPIFromModule#2.class) - no extra argument here when the ModuleExtension executes the ServiceAPIFromModule#1. And that does not work neither - for same above issues.
Now - if you ask me to add a second argument to ServiceLoader in Module#1 - then there is a no go - because Module#1 may be a 3rd party product that I cannot change, as example. Thus the ServiceLoader.load with one argument is the only option that can be available.
At the same time, Module#1 code should not be impacted by the jboss-module/as7 architecture - one same simple reason: portability.
Any existing jar file can be always be viewed as a Module - but not as an extension - which is ok !
Thus as a Module, if it's using ServiceLoader with one argument it should work with no code changes ! Otherwise you impleciltely are telling me that the exiting jar file is no longer portable when using it from ModuleExtension ! And this makes jboss-modules not to be flexible and imposes extra constrains that, to me, do not look to be required.
Think about that jar file can be used as a Module from a WAr, RAR and why not from a ModuleExtension ?!?
Again, once I am in the Module#1 code I should be able to do a ServiceLoader.load - with only one argument as any war file does when it is deployed - if the module.xml has set a dependecy on a module and if services="import" has been set in the ModuleExtension as in the war.
So far, I am not getting that ! And again, even if it looks stuborn, I think from design point of view I should !
BR,
Dan S.