]
Pete Muir updated CDITCK-79:
----------------------------
Component/s: Tests
Fix Version/s: 1.0.1.CR1
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
Fix For: 1.0.1.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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: