Pete Muir [http://community.jboss.org/people/petemuir] replied to the discussion
"Implementing a non-flat deployment for Weld Integration" To view the discussion, visit: http://community.jboss.org/message/546189#546189 -------------------------------------------------------------- > 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 ;-) -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546189#546189] Start a new discussion in JBoss Microcontainer Development POJO Server at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2116]
_______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
