November 2009 - weld-issues - Jboss List Archives

[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

16 years, 2 months

2
5
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

16 years, 2 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

16 years, 2 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

16 years, 2 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

16 years, 2 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

16 years, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (WELD-307) Weld needs to treat a passivating pseudo-scope as a definition error as part of beforeBeanDiscovery.addScope()

by Pete Muir (JIRA)

Weld needs to treat a passivating pseudo-scope as a definition error as part of beforeBeanDiscovery.addScope() -------------------------------------------------------------------------------------------------------------- Key: WELD-307 URL: https://jira.jboss.org/jira/browse/WELD-307 Project: Weld Issue Type: Bug Components: Bootstrap and Metamodel API Reporter: Pete Muir Fix For: 1.0.1.CR1 *.deployment.lifecycle.broken.passivatingScope.AddingPassivatingScopeTest.testAddingScope -- 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

16 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (CDITCK-53) Remove library version definitions from build.properties

by Jozef Hartinger (JIRA)

Remove library version definitions from build.properties -------------------------------------------------------- Key: CDITCK-53 URL: https://jira.jboss.org/jira/browse/CDITCK-53 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.0.GA Reporter: Jozef Hartinger Priority: Minor Fix For: 1.0.1.CR1 Library version definitions like weld-deployer.version=5.2.0-SNAPSHOT weld.version=1.0.0-SNAPSHOT are present in the jsr299-tck-1.0.0/weld/jboss-as/build.properties although they are not used and confusing. -- 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

16 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (WELD-318) Wrapping InjectionTarget does not work for Beans with a Producer field

by Stuart Douglas (JIRA)

Wrapping InjectionTarget does not work for Beans with a Producer field ---------------------------------------------------------------------- Key: WELD-318 URL: https://jira.jboss.org/jira/browse/WELD-318 Project: Weld Issue Type: Bug Reporter: Stuart Douglas I am trying to wrap InjectionTarget to set field values at bean creation time. This works perfectly unless the bean has a producer field. When the bean has a producer the InjectionTarget.postConstruct is never called (even though the PostConstruct method on the bean is called). -- 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

16 years, 2 months

2
15
0 / 0

[JBoss JIRA] Created: (CDITCK-58) Issue with org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest

by Vivek Pandey (JIRA)

Issue with org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest ------------------------------------------------------------------------------- Key: CDITCK-58 URL: https://jira.jboss.org/jira/browse/CDITCK-58 Project: CDI TCK Issue Type: CTS Challenge Security Level: Public (Everyone can see) Affects Versions: 1.0.1.CR1 Environment: JDK 6 u15, Snow Leopard, GlassFish v3 b72, CDI TCK 1.0.1 RC1 Reporter: Vivek Pandey For context package test: org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest There are 2 assertions on glassfish v3: org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest.testRequestScopeActiveDuringCallToEjbTimeoutMethod(EJBRequestContextTest.java:36) org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest.testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(EJBRequestContextTest.java:53) I think Weld is not doing the right thing here. See the analysis below: In FMSModeIII, the timer expire time is 200 ms. The test waits for 250 ms so that timeout() is invoked and sets requestScopeActive to true. In the EJBRequestcontextCode: flightManagementSystem.climb(); ==> a timer is created with 200 ms duration Thread.sleep(250); ==> sleep for 250 ms and timeout is called assert flightManagementSystem.isRequestScopeActive(); ==> Due to the exception below, the flag requestScopeActive, which was supposed to be set in timeout() method was never set. Caused by: javax.enterprise.context.ContextNotActiveException: No active contexts for scope type javax.enterprise.context.RequestScoped at org.jboss.weld.BeanManagerImpl.getContext(BeanManagerImpl.java:928) at org.jboss.jsr299.tck.tests.context.request.ejb.FMSModelIII.timeout(FMSModelIII.java:50) Under jsr 299 spec 6.7.1: -------- The request context is provided by a built-in context object for the built-in scope type @RequestScoped. The request scope is active: * during any remote method invocation of any EJB, during any asynchronous method invocation of any EJB, during any call to an EJB timeout method and during message delivery to any EJB message-driven bean, and ---------- However during timeout() method call beanManager.getContext(RequestScoped.class).isActive() returns false. Which seems to violate the above requirement in 6.7.1. -- 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

16 years, 2 months

2
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues November 2009