Thanks Jozef! I agree with you that it is best to create bda according to classloading and wire the graph according to classloading hierarchy.
On Mon, May 25, 2015 at 11:08 AM, Jozef Hartinger <[email protected]> wrote: > > On 05/25/2015 11:07 AM, Emily Jiang wrote: > > Thank you Jozef! I also figured this out after I debugged the case > further and reread the javadoc. Would you recommend to create one bda for > every given class (not app class) or we should design a special archive to > hold all this kind of classes or it does not matter much? > > You'll need to honor accessibility in these archives. Therefore, for > example Integer and Long can share a single bean archive but e.g. a > different class that is not accessible from Integer and Long needs to be > put in a separate bean archive and accessibility of the classes needs to be > reflected in the BDA graph. > > One option we use in WildFly for these additional bean archives is to have > a bean archive per classloader. > > > As for adding the bda to the graph, from my understanding, these classes > should be visible to every other classes in the deployment. Therefore, this > new bda should be accessible to all other bdas in this deployment, right? > > Yes, it is true for this particular class. If however > loadBeanDeploymentArchive() was called for a different class (e.g. for a > class from a web archive's library jar that is not itself a bean archive) > then, as such class is not necessarily accessible from every bean archive, > neither should be the returned bean archive. > > Thanks > Emily > > On Mon, May 25, 2015 at 6:54 AM, Jozef Hartinger <[email protected]> > wrote: > >> Emily, >> >> see the JavaDoc here: >> http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/bootstrap/spi/Deployment.html#loadBeanDeploymentArchive-java.lang.Class >> - >> >> Specifically, it says: >> >> " If the deployment archive containing the given class is not currently >> a bean deployment archive, it must be added to the bean deployment archive >> graph and returned." >> >> Therefore, even though the given class is not part of an existing bean >> archive, it should be handled by the integrator, added to the bean archive >> graph and returned from the method. >> >> HTH, >> >> Jozef >> >> >> On 05/24/2015 09:58 AM, Emily Jiang wrote: >> >> I'm trying to run the cdi tck but got an error for the following test: >> In the test: >> org.jboss.cdi.tck.tests.definition.bean.custom.CustomBeanImplementationTest >> Method: arquillianBeforeClass >> >> >> >> Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-000817: >> Unable to find Bean Deployment Archive for class java.lang.Integer >> at >> org.jboss.weld.util.DeploymentStructures.getOrCreateBeanDeployment(DeploymentStructures.java:39) >> at >> org.jboss.weld.bootstrap.events.AbstractBeanDiscoveryEvent.getOrCreateBeanDeployment(AbstractBeanDiscoveryEvent.java:70) >> at >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.processBean(AfterBeanDiscoveryImpl.java:86) >> at >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finish(AfterBeanDiscoveryImpl.java:186) >> ... 15 more >> >> It seems that Custom bean was added by an extension but the bean >> implements Bean<Integer>. Surely the java.lang.Interger should not be any >> bean archives. Can someone tell me what I might done wrong? Will integrator >> need to do something to cater for all of the java.x classes or Weld should >> handle this? >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> [email protected] >> >> >> _______________________________________________ >> weld-dev mailing >> [email protected]https://lists.jboss.org/mailman/listinfo/weld-dev >> >> >> > > > -- > Thanks > Emily > ================= > Emily Jiang > [email protected] > > > -- Thanks Emily ================= Emily Jiang [email protected]
_______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
