January 2010 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (CDITCK-93) Remove or fix all broken tests

by Pete Muir (JIRA)

Remove or fix all broken tests ------------------------------ Key: CDITCK-93 URL: https://jira.jboss.org/jira/browse/CDITCK-93 Project: CDI TCK Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tests Reporter: Pete Muir Fix For: 1.0.1.CR1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (CDITCK-68) Event not fired in Glassfish

by Santiago Pericas-Geertsen (JIRA)

Event not fired in Glassfish ---------------------------- Key: CDITCK-68 URL: https://jira.jboss.org/jira/browse/CDITCK-68 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.0.GA Environment: Solaris x86 / JDK6u16 / GF v3 Reporter: Santiago Pericas-Geertsen In the test, *.extensions.observer.broken.definitionError.ProcessObserverMethodErrorTest there's a EventB class and an extension class ProcessObserverMethodObserver with an observer method for EventB. In that method, there is a call to, event.addDefinition(...) which is expected to trigger a deployment error in the test. However, AFAICT the observer method is never called because EventB is never fired, resulting in the deployment to succeed and the test to fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (WELD-386) Weld fails to load Extension classes which aren't declared public

by Pete Muir (JIRA)

Weld fails to load Extension classes which aren't declared public ----------------------------------------------------------------- Key: WELD-386 URL: https://jira.jboss.org/jira/browse/WELD-386 Project: Weld Issue Type: Feature Request Components: Bootstrap and Metamodel API Reporter: Pete Muir Fix For: 1.0.1.CR1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (CDITCK-95) Remove installed libraries tests

by Pete Muir (JIRA)

Remove installed libraries tests -------------------------------- Key: CDITCK-95 URL: https://jira.jboss.org/jira/browse/CDITCK-95 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Infrastructure Environment: Solaris x86 / JDK 16u6 / GF v3 Reporter: Santiago Pericas-Geertsen Fix For: 1.0.1.CR1 We have found that certain TCK test load classes from jsr299-tck-api.jar and jsr299-tck-impl.jar, but these jars are not normally included in the generated application bundles. An example of such a test is: *.deployment.packaging.installedLibrary.WarInstalledLibraryTest.test which looks for: org/jboss/jsr299/tck/tests/deployment/packaging/installedLibrary/Bar This test fails with GF as these classes are not available to applications. Should jsr299-tck-api.jar and jsr299-tck-impl.jar be bundled with apps? (We can provide a complete list of tests that depend on these TCK jars if needed). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (CDITCK-69) Issues with passivation capable injected beans tests

by Vivek Pandey (JIRA)

Issues with passivation capable injected beans tests ---------------------------------------------------- Key: CDITCK-69 URL: https://jira.jboss.org/jira/browse/CDITCK-69 Project: CDI TCK Issue Type: CTS Challenge Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.1.CR1 Environment: jsr 299 tck 1.0.1.CR1, glassfish v3, jdk6 u15 Reporter: Vivek Pandey We have this failure for implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest: [testng] java.lang.ClassCastException: cannot assign instance of javassist.util.proxy.SerializedProxy to field org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.ManagedBean.persistenceContext of type javax.persistence.EntityManager in instance of org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.ManagedBean [testng] at java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2032) [testng] at java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1212) [testng] at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1953) [testng] at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) [testng] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) [testng] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) [testng] at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) [testng] at org.jboss.jsr299.tck.AbstractJSR299Test.deserialize(AbstractJSR299Test.java:49) [testng] at org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest.testPassivationOfPersistenceContext(PersistenceContextInjectionTest.java:74) [testng] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Stack trace shows that the error is coming from javassist/Weld. Error is thrown while executing this code while executing org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest.testPassivationOfPersistenceUnit org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest.testPassivationOfPersistenceContext -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
8
0 / 0

[JBoss JIRA] Created: (CDITCK-80) Issue surrounding Bean.destroy() behavior

by Vivek Pandey (JIRA)

Issue surrounding Bean.destroy() behavior ----------------------------------------- Key: CDITCK-80 URL: https://jira.jboss.org/jira/browse/CDITCK-80 Project: CDI TCK Issue Type: CTS Challenge Security Level: Public (Everyone can see) Affects Versions: 1.0.1.CR1 Environment: jdk6 u15, glassfish v3 Reporter: Vivek Pandey org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextDesctructionTest seems to be invalid or jsr299 7.3.6 needs to clarify. Read below: Sec 7.3.6 Lifecycle of resources of JSR299 layout this asseertion: "When the create() method of a Bean object that represents a resource is called, the container creates and returns a con- tainer-specific internal reference to the Java EE component environment resource, entity manager, entity manager factory, remote EJB instance or web service reference. This reference is not directly exposed to the application. Before injecting or returning a contextual instance to the application, the container transforms its internal reference into an object that implements the bean types expected by the application and delegates method invocations to the underlying re- source, entity manager, entity manager factory, remote EJB instance or web service reference. This object must be passiva- tion capable. When the destroy() method is called, the container discards this internal reference and performs any cleanup required of state associated with the client or transaction." And there is this TCK test org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextDesctructionTest which does the following : CreationalContext<ManagedBean> creationalContext = getCurrentManager().createCreationalContext(managedBean); ManagedBean instance = managedBean.create(creationalContext); EntityManager em = instance.getPersistenceContext(); assert em.isOpen(); ==>managedBean.destroy(instance, creationalContext); assert !em.isOpen(); When I looked in to the debugger I see that managedBean.destroy() call results in to calling GlassFish injected EntityManagerWarpper.close() which correctly throws InvalidStateException. This is as per JPA spec where EntityManager.close() is supposed to thro IllegalStateException for container manager EntityManager. See http://java.sun.com/javaee/5/docs/api/javax/persistence/EntityManager.htm.... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (CDITCK-56) mispackaged application (SimpleBeanDefinitionTest.ear) caused deployment failure on glassfish v3

by Hong Zhang (JIRA)

mispackaged application (SimpleBeanDefinitionTest.ear) caused deployment failure on glassfish v3 ------------------------------------------------------------------------------------------------ Key: CDITCK-56 URL: https://jira.jboss.org/jira/browse/CDITCK-56 Project: CDI TCK Issue Type: CTS Challenge Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.1.CR1 Environment: Ubuntu/X86 Reporter: Hong Zhang Priority: Critical During test run, org.jboss.jsr299.tck.tests.implementation.simple.definition.SimpleBeanDefinitionTest.ear failed to deploy on glassfish v3. Looking at the ear packaging, it seems this application was mispackaged which caused the deployment failure: SimpleBeanDefinitionTest.jar is declared as an ejb jar in application.xml. But the ejb-jar.xml inside this jar does not define any EJBs, and none of the packaged classes in this jar contain any ejb component annotations (@Stateless, @Stateful, @MessageDriven, @Singleton). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
8
0 / 0

[JBoss JIRA] Created: (CDITCK-74) Test fails in GF due to incorrect assumption

by Santiago Pericas-Geertsen (JIRA)

Test fails in GF due to incorrect assumption -------------------------------------------- Key: CDITCK-74 URL: https://jira.jboss.org/jira/browse/CDITCK-74 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.1.CR1 Environment: Solaris x86 / JDK 6u16 / GF v3 Reporter: Santiago Pericas-Geertsen The test *.event.observer.enterprise.EnterpriseEventInheritenceTest includes the following assertion: egg.getClassesVisited().iterator().next().equals(Farmer.class) and the same assertion for the class StockWatcher. The classes Farmer and StockWatcher are stateful EJBs. The EJB container in GF subclasses these to create serializable versions. These new classes are named _Farmer_Serializable and _StockWatcher_Serializable and are therefore different from Farmer and StockWatcher. The assertion above fails in GF as a result. The other assertions in the test are fine, but the class equal assertion seems to strong to be portable across containers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
2
0 / 0

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

by Hong Zhang (JIRA)

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) Affects Versions: 1.0.0.GA Environment: X86/Ubuntu Reporter: Hong Zhang 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: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (CDITCK-92) Create nightly build for distro

by Pete Muir (JIRA)

Create nightly build for distro ------------------------------- Key: CDITCK-92 URL: https://jira.jboss.org/jira/browse/CDITCK-92 Project: CDI TCK Issue Type: Task Security Level: Public (Everyone can see) Components: Infrastructure Reporter: Pete Muir Fix For: 1.0.1.CR1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues January 2010