Flavia Rainone wrote:
Pete Muir wrote:
I've been thinking about correctness all this time. If somebody places a jar in lib and expects that the beans are created upfront when AS starts, then this would not work using your approach.
Ok, I think we've got crossed wires. You can't deploy a library jar in some "context" outside a deployment. The beans don't get created or anything outside the context of a deployment.
Another way to think of it is that a library in default/lib with a beans.xml in it works just like a library in WEB-INF/lib.
In that case, why the lazy approach wouldn't work?
From what I can see, if it works just like a library in WEB-INF/lib, it means that we will need to provide a BDA for a lib jar only when Weld requests for one through loadBeanDeploymentArchive, right?
Or, if I'm wrong, do you mean that a BDA for every lib jar with a META-INF/beans.xml should be provided as direct or indirect result of BeanDeploymentArchive.getBeanDeploymentArchives() for every BDA in a Deployment?
Explaining better, given commos/lib/mylib.jar with the following structure:
mylib.jar
|_
META-INF/beans.xml
|_
whatever classes in here
Say we create a BDA upfront, let's call it MY_LIB_BDA, and add this BDA to DefalutDomain Classpath. No deployment is created upfront.
Now, say my-ejb.jar with a META-INF/beans.xml file is deployed to deploy dir. We create a Deployment for it, of course, and we create a BDA for it as well. This BDA, called MY_EJB_BDA, belongs to Default Domain Classpath. So, when Weld invokes MY_EJB_BDA.getBDAs(), it should , directly on indirectly (i.e., by walking on the BDA graph structure), reach MY_LIB_BDA?
This is different from the lazy approach because, with this second approach, you are not required to call loadBeanDeploymentArchive in order to obtain MY_LIB_BDA. A simple BeanDeploymentArchive.getBeanDeploymentArchives will get you there.
Is that what Weld requires us to do?
Yes. If there is an accessible (i.e. classes can be loaded from it) library jar with META-INF/beans.xml, then Weld expects you to return it as part of the BDA graph of the Deployment.
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).
Because the Java EE/CDI specs require it.
BTW, I've read the spec sometime ago. Of course I don't remember all the details so, if you think rereading some specific part of it might be useful, let me know.
I simply meant that the reason we have to load library jars as BDAs is because the spec says so ;-)