[JBoss JIRA] Created: (CDITCK-57) Issues in testGetStereotypesCalled and testIsNullableCalled
by Vive Pandey (JIRA)
Issues in testGetStereotypesCalled and testIsNullableCalled
-----------------------------------------------------------
Key: CDITCK-57
URL: https://jira.jboss.org/jira/browse/CDITCK-57
Project: CDI TCK
Issue Type: CTS Challenge
Security Level: Public (Everyone can see)
Components: Tests
Affects Versions: 1.0.1.CR1
Reporter: Vive Pandey
The following tests in CDI TCK 1.0.1 RC1 are failing on GlassFish v3. the tests seem to be invalid. See below:
*.definition.bean.custom.CustomBeanImplementationTest.testGetStereotypesCalled
*.definition.bean.custom.CustomBeanImplementationTest.testIsNullableCalled
the first one testGetStereotypesCalled is supposed to be set during called to Bean.getStereotypes(), and its never called. Same applies for testIsNullableCalled, which is supposed to return true when Bean.isNullable() is called, but is never called.
jsr 299 spec in 5.1.1 lays out this requirement for custom beans:
For a custom implementation of the Bean interface defined in Section 11.1, "The Bean interface", the container calls isAlternative() to determine whether the bean is an alternative, and getBeanClass() and getStereotypes() to determ- ine whether an alternative is selected in a certain bean archive.
In this test case, isAlternative() returns false, and correctly so because the associated beans.xml does not define any alternative beans or there is no @Alternative in the bean. This is defined in sec 5.1.1 and 11.1.
According to Bean.isNullable() returns true only if the Bean.create(), here CatBean.create() sometimes return null. In this case it never
public Cat create(CreationalContext<Cat> creationalContext){
return new Cat("kitty");
}
So in my investigation both these assertions testGetStereotypesCalled() and testIsNullableCalled() are invalid.
--
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
15 years, 1 month
[JBoss JIRA] Created: (CDITCK-85) The CDI TCK assumes ear support by all impls
by Kyle Grucci (JIRA)
The CDI TCK assumes ear support by all impls
--------------------------------------------
Key: CDITCK-85
URL: https://jira.jboss.org/jira/browse/CDITCK-85
Project: CDI TCK
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.0.1.CR1
Environment: All
Reporter: Kyle Grucci
The Web Profile spec falls under the Java EE 6 JSR which just went final. Since CDI is a requirement of the EE Web Profile, the CDI TCK must be able to run against it (ie it can't assume full EE and thus ear support). This is currently not the case since the TCK contains some ear files and some tests which rely upon them. At the very least it probably makes sense to have a second testsuite XML file which doesn't assume full EE. Otherwise impls of CDI which are not Full EE impls cannot run and pass the CDI TCK since the current testsuite xml file contains some ears.
Until you are able to provide the alternate xml file, would it be possible for you to provide use with the tests to exclude whan not running on Full EE - (i.e. the tests which use ear files)?
Thanks.
--
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
15 years, 1 month
[JBoss JIRA] Created: (WELD-338) weld-numberguess example doesn't work with jboss-6.0.0.M1 in cluster
by Martin Gencur (JIRA)
weld-numberguess example doesn't work with jboss-6.0.0.M1 in cluster
--------------------------------------------------------------------
Key: WELD-338
URL: https://jira.jboss.org/jira/browse/WELD-338
Project: Weld
Issue Type: Bug
Components: Examples
Affects Versions: 1.0.0.GA
Reporter: Martin Gencur
Fix For: 1.0.1.CR1
Trying to continue with the same session id on different jboss instance and web browser leads to the following exception on the instance's console:
12:41:21,767 WARN [SessionBasedJBossCacheService] Problem accessing session data : class java.lang.NullPointerException null
Steps to reproduce:
1) download jboss-6.0.0.M1 (for example from http://reports.qa.atl.jboss.com/release_tests/binaries/JBossAS/jboss-6.0....)
2) unzip it twice to different folders
3) run the first instance from its bin directory: ./run.sh -c all -g DocsPartition -u 239.255.101.101 -b localhost -Djboss.messaging.ServerPeerID=1 -Djboss.service.binding.set=ports-default
4) run the second instance from its bin directory: ./run.sh -c all -g DocsPartition -u 239.255.101.101 -b localhost -Djboss.messaging.ServerPeerID=2 -Djboss.service.binding.set=ports-01
5) edit examples/jsf/numberguess/src/main/webapp-jboss5/WEB-INF/web.xml (add <distributable/> as its first tag so that the application..... !!! I don't know for sure if it is enough, maybe this is the problem !!!)
6) run mvn package in examples/jsf/numberguess
7) copy resulting war file (weld-numberguess.war) from numberguess/target/ directory to serve/all/farm directory at first jbossAS instance
8) remove cookies for "localhost" domain from web browser, disable cookies
9) go to http://localhost:8080/weld-numberguess/home.jsf, play for 2-3 times with application (try to guess a number)
10) copy&paste the url (for example "http://localhost:8080/weld-numberguess/home.jsf;jsessionid=VBobYX3Itd9fUI...") into another window with cookies disabled, change port number from 8080 to 8180 and go to the page
11) now you can see the exception in the second jboss instance's console and the application behaves like it doesn't know this session and starts from scratch
--
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
15 years, 1 month
[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
15 years, 1 month
[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
15 years, 1 month
[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
15 years, 1 month
[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
15 years, 1 month
[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
15 years, 1 month
[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
15 years, 1 month