[jboss-user] [JBoss Microcontainer Development POJO Server] - Implementing a non-flat deployment for Weld Integration

[Pete Muir]

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]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20100604/0ab0ec02/attachment-0001.html