Ales Justin wrote:
The loadBeanDeploymentArchive method solely exists for the case that someone adds a bean based on a class which isn't present in the BDA graph via a CDI lifecycle listener. For every bean defined in such a way, Weld calls loadBeanDeploymentArchive, expecting the correct BDA to be returned.
IOW this is a kinda a two stage process - firstly the BDAs which are defined declaratively (META-INF/beans.xml) are handed to Weld, and then BDAs which are defined programatically are loaded by Weld (via loadBeanDeploymentArchive).
So, if I understand this correctly, BDAs created via "loadBeanDeploymentArchive" don't require beans.xml?
Simply add the class' owner jar as a BDA archive?
I have just chatted with Pete, and this is what he has to say about it:
(11:43:25) Pete: so it looks like from what you say that the BDA you are returning from loadBDA is pre-populated with everything in that archive?
(11:44:00) Flavia: Yes, it has always been like this. The only difference is that a few classes were missing.
(11:45:59) Pete: hmm, I think the intention is to only have the classes in that BDA that have been explicitly requested via loadBDA
(11:46:07) Flavia: Aha!
(11:46:16) Flavia: That is a missing piece of the puzzle then
(11:46:18) Pete: (of course, if it's an existing BDA, then it should have the regular classes)
(11:47:14) Flavia: As I said in the forum, mapping a BDA to a ClassLoader
(11:47:26) Flavia: puts several jars in the same umbrella.
(11:47:54) Flavia: So, currently, the BDA "umbrella" for several jars contain only the classes of the jars that have the beans.xml file. Is this correct?
(11:48:02) Flavia: From the Weld point of view
(11:48:29) Pete: i think that sounds fine to me
(11:48:52) Flavia: Ok, so in that case, I think that Ales's suggestion is the way to go
(11:48:56) Flavia: Ales suggested a third option
(11:49:25) Flavia: According to Ales, what is there is correct the way it is, which is also what you are saying
(11:49:45) Flavia: The only thing here is that, if a loadBeanDeploymentArchive is invoked with a class that is not in the BDA before
(11:50:10) Flavia: considering the BDA already exists but one of the jars it represents lacks the META-INF/beans.xml file
(11:50:29) Flavia: in that case, the class should be added to the already existing BDA before it is returned
(11:51:25) Pete: i think in our case
(11:51:29) Pete: it depends on the classloader
(11:51:37) Pete: /Module
(11:51:52) Pete: if it's in a Module which already has an associated BDA, then add it to that BDA and return that BDA
(11:52:05) Pete: if it's in a Module with no BDA, create a new BDA with just that class in
(11:52:25) Flavia: Cool, that's easy to do
(11:52:59) Flavia: So, I should always add the class, and never start scanning the jar it belongs to in order to add all the classes to the BDA?
(11:53:31) Pete: for loadBDA, no, never
(11:53:42) Flavia: Aha! Now I think I get it
...
(11:55:05) Pete: basically, you can think of loadBDA as a special way of adding classes to BDA which only adds those classes
(11:55:24) Flavia: Yes... Ales and I were talking about this today on the call
(11:55:39) Flavia: His question is when, in which scenario, loadBDA is called for a class that is not in the BDA?
(11:55:44) Pete: ah
(11:55:53) Pete: well, if you look at CDI lifecycle events
(11:56:05) Pete: you can see that people can create a Bean<> for any class that is on the classpath
(11:56:14) Pete: so to properly enforce the accessibility rules
(11:56:21) Pete: we need to know where it is in the BDA graph
(11:56:56) Flavia: Hm... so you may end up needing to create a bean of a type that is not in the BDA
(11:57:05) Pete: exactly
So, in a nutshell, all I have to do is change DeploymentImpl.loadBDA() so it adds the Class to the BDA if the BDA it is returning lacks that class.