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 <jharting(a)redhat.com>
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 <jharting(a)redhat.com>
wrote:
> Emily,
>
> see the JavaDoc here:
>
http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/bootstrap/...
> -
>
> 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
> ejiang(a)apache.org
>
>
> _______________________________________________
> weld-dev mailing
listweld-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/weld-dev
>
>
>
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org