[weld-issues] [JBoss JIRA] Closed: (CDITCK-79) test failures in implementation.producer.method.definition.enterprise.EnterpriseProducerMethodDefinitionTest

test failures in implementation.producer.method.definition.enterprise.EnterpriseProducerMethodDefinitionTest ------------------------------------------------------------------------------------------------------------ Key: CDITCK-79 URL: https://jira.jboss.org/jira/browse/CDITCK-79 Project: CDI TCK Issue Type: Bug Security Level: Public(Everyone can see) Components: Tests Affects Versions: 1.0.0.GA Environment: X86/Ubuntu Reporter: Hong Zhang Assignee: Pete Muir Fix For: 1.0.1.CR1, 1.1.0.CR1 Test failure #1: assert getInstanceByType(Egg.class,new AnnotationLiteral<Yummy>() {}).getMother().getClass().equals(AndalusianChicken.class) This test failed due to this stack trace: Caused by: java.lang.NoSuchMethodException: Method produceEgg() not implemented by instance org.jboss.jsr299.tck.tests.implementation.producer.method.definition.enterprise.AndalusianChickenLocal_$$_javassist_12 Looking into the weld RI code, in Reflections.lookupMethod, when it iterates through all the super classes/super interfaces for "AndalusianChickenLocal_$$_javassist_12" to look for the method, it never goes to the "Chicken" class (it did go to AndalusianChickenLocal, java.io.Serializable etc). Earlier in the DependentContext.get method, the passed in contextual param is an "AndalusianChicken" object (which seems correct), and the instance returns is "AndalusianChickenLocal_$$_javassist_12". Is this correct? If the returned instance is correct, why the the super class "Chicken" of the "AndalusianChicken" was never iterated in the Reflections.lookupMethod when looking for the method? Test failure #2: assert getInstanceByType(Apple.class,new AnnotationLiteral<Yummy>() {}).getTree().getClass().equals(AppleTree.class); After stepping into the weld TCK/RI code, I noticed getInstanceByType(Apple.class,new AnnotationLiteral<Yummy>() {}).getTree().getClass() returns "_AppleTree_Serializable" class which does not equal to "AppleTree.class", so the assertion failed and the test failed. After talking with Pete about these failures, he suggested to exclude both tests. He wants to look at test failure #1 for the RI side of the things, why the "Chicken" was not processed as part of the super class. But as #1 will fail with the same cause as #2 anyways, we should just exclude both tests for now. Pete could spawn off a RI issue for #1 as needed.