So, these features that we need to support provide the arguments as to why we should mirror the ClassLoader structure instead of implementing this from scratch.
Yeah, re-inventing this would be a nightmare. ;-)
Pete also pointed out an important behaviour that should be fixed. In a nutshell, all archives visible to a BDA are scanned. In the given scenario: ejb.jar A reaches lib2. In lib2 we have a ClassPath reference in the manifest to lib3, which is not in the classpath of the server... it is somewhere in the filesystem. In this case, for what I understood from Pete's explanations, lib3 is going to be scanned for CDI stuff. But this shouldn't happen, so we would also need a way of differentiating lib3 from lib2. I'll stop my explanation here, as I think Pete can fill in the blanks and explain this much better :-)
I guess this is the discussion we already had once: actual Weld deployment vs. static "library"?
So, Ales, how do you think this should be done? I think we have plenty of code in the ClassPools that do exactly that, mirror the ClassLoader structure in a way that allows us to find the classes and xml files in META-INF dirs. Maybe there is a way of reusing part of the ClassPool code to do this?
It is similar in a way, but I don't see how you would be able to re-use it.
In new CL layer it's one Module per ClassLoader and vice versa.
Each Module / ClassLoader belongs to some Domain.
So, we would have to keep track of Modules and how are they wired hierarchicaly and grouped by Domain.
A Module can see any ancestor Module and all Modules in its Domain and ancestor Domains.
I would differentiate between application's explicit Modules and what it can reach,
hence you don't scan yourself too deep; e.g. into default Domain.
This way it should be also easy to support a notin if libraries as long as they are deployed the same way / over new CL layer.