July 2011 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (CDITCK-205) Add test to verify extensions in non-bean archives are loaded

by Dan Allen (JIRA)

Add test to verify extensions in non-bean archives are loaded ------------------------------------------------------------- Key: CDITCK-205 URL: https://issues.jboss.org/browse/CDITCK-205 Project: CDI TCK Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Dan Allen Priority: Minor Add a test to answers this question: Does an extension have to be in an bean archive in order to be loaded? Section 11.5 states: "An extension is a service provider of the service javax.enterprise.inject.spi.Extension declared in META-INF/services." If one assumes that "service provider" refers to the term defined in the jar specification [1], then one would conclude that an extension does not have to be in a bean archive to be recognized (these are orthogonal concerns). A test for this scenario is available in the OpenTCK project and may be ported to the CDI TCK. [2] [1] http://download.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#Se... [2] https://github.com/opentck/javaee_cdi/tree/master/src/test/java/org/opent... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (CDITCK-206) Add test to verify visibly of beans registered explicitly through an extension in non-bean archives

by Dan Allen (JIRA)

Add test to verify visibly of beans registered explicitly through an extension in non-bean archives --------------------------------------------------------------------------------------------------- Key: CDITCK-206 URL: https://issues.jboss.org/browse/CDITCK-206 Project: CDI TCK Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Dan Allen Add a test that answers this question: Can an extension register a bean programmatically for a class that resides in another non-bean archive? This question requires a short example which is available in the OpenTCK test suite and may be ported to the CDI TCK [1]. Assume one archive, a.jar, has the following contents: org/opentck/javaee/cdi/spi/beforebeandiscovery/BeanClassToRegister.class A second archive, b.jar, has the following contents: org/opentck/javaee/cdi/spi/beforebeandiscovery/AnotherBeanClassToRegister.class org/opentck/javaee/cdi/spi/beforebeandiscovery/AnotherManualBeanRegistrationExtension.class org/opentck/javaee/cdi/spi/beforebeandiscovery/ManualBeanRegistrationExtension.class META-INF/services/javax.enterprise.inject.spi.Extension AnotherBeanClassToRegister has an injection point of type BeanClassToRegister: public class AnotherBeanClassToRegister { @Inject private BeanClassToRegister collaborator; } BeanClassToRegister and AnotherBeanClassToRegister are added as beans programmatically in respective extensions listed in the service provider descriptor: public class ManualBeanRegistrationExtension implements Extension { public void registerBeans(@Observes BeforeBeanDiscovery event, BeanManager bm) { event.addAnnotatedType(bm.createAnnotatedType(BeanClassToRegister.class)); } } public class AnotherManualBeanRegistrationExtension implements Extension { public void registerBeans(@Observes BeforeBeanDiscovery event, BeanManager bm) { event.addAnnotatedType(bm.createAnnotatedType(AnotherBeanClassToRegister.class)); } } The two libraries, a.jar and b.jar are bundled in a web archive, test.war WEB-INF/lib/a.jar WEB-INF/lib/b.jar WEB-INF/beans.xml Deploying this archive to the reference implementation fails with an error message that the injection point from above cannot be satisfied. There appears to be a visibility problem across bean archives in this case. Adding META-INF/beans.xml to a.jar and removing the ManualBeanRegistrationExtension from b.jar resolves the issue in the reference implementation. [1] https://github.com/opentck/javaee_cdi/tree/master/src/test/java/org/opent... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (WELD-878) WeldPhaseListener fails to activate conversation context if conversation is not found

by Jarkko Hyöty (JIRA)

WeldPhaseListener fails to activate conversation context if conversation is not found ------------------------------------------------------------------------------------- Key: WELD-878 URL: https://issues.jboss.org/browse/WELD-878 Project: Weld Issue Type: Bug Components: Conversations, Web Tier integration (JSF, JSP, EL and Servlet) Affects Versions: 1.1.0.Final Environment: Glassfish 3.1 B43 updated with weld-1.1.0-SNAPSHOT (weld-osgi-bundle-1.1.0-20110329.041630-9.jar) Reporter: Jarkko Hyöty It seems that org.jboss.weld.jsf.WeldPhaseListener fails to activate conversation context if a conversation is not found by the supplied conversation id. This problem is potentially related to [SEAMCATCH-46],[WELD-855]. JSR-299 6.7.4 Conversation context lifecycle has a requirement that 'If the propagated conversation cannot be restored, the container _must associate the request with a new transient conversation_ and throw an exception of type javax.enterprise.context.NonexistentConversationException from the restore view phase of the JSF lifecycle.'. However, the implementation of org.jboss.weld.jsf.WeldPhaseListener.activateConversations fails to do that if a conversation is not found by the conversation id. {code} private void activateConversations(FacesContext facesContext) { ConversationContext conversationContext = instance().select(HttpConversationContext.class).get(); String cid = getConversationId(facesContext, conversationContext); log.debug(RESUMING_CONVERSATION, cid); if (cid != null && conversationContext.getConversation(cid) == null) { throw new NonexistentConversationException(NO_CONVERSATION_FOUND_TO_RESTORE, cid); } conversationContext.activate(cid); } {code} Recovering from the exception becomes difficult since the context is not active. Typical symptom is 'java.lang.IllegalStateException: Unable to load current conversations from the associated request, something went badly wrong when associate() was called at org.jboss.weld.context.AbstractConversationContext.getCurrentConversation(AbstractConversationContext.java:413)' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

6
8
0 / 0

[JBoss JIRA] Created: (CDITCK-214) Managed bean not given a @Named annotation in Non-Contextual injection test

by Bob Nettleton (JIRA)

Managed bean not given a @Named annotation in Non-Contextual injection test --------------------------------------------------------------------------- Key: CDITCK-214 URL: https://issues.jboss.org/browse/CDITCK-214 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Bob Nettleton The following test case: org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.InjectionIntoNonContextualComponentTest.testInjectionIntoJSFManagedBean verifies that a JSF managed bean can be a target for CDI injection. The .jsp in the test case (ManagedBeanTestPage.jsp) relies on an Expression Langage name ("farm") in order to locate this bean. The managed bean in question: org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.Farm does not include a @Named annotation. Section 2.5.3 of the CDI Specification states that: "If @Named is not declared by the bean, nor by its stereotypes, a bean has no EL name." Based on this line in the spec, it appears that this test may be in error. If the bean does not have an EL name, the bean cannot be located by the EL Resolver. If my interpretation of the spec is correct here, I request that this test be excluded. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

3
3
0 / 0

[JBoss JIRA] Created: (CDITCK-175) Tests from org.jboss.jsr299.tck.tests.interceptors.definition.broken.finalClassInterceptor should be separated

by Marius Bogoevici (JIRA)

Tests from org.jboss.jsr299.tck.tests.interceptors.definition.broken.finalClassInterceptor should be separated -------------------------------------------------------------------------------------------------------------- Key: CDITCK-175 URL: https://jira.jboss.org/browse/CDITCK-175 Project: CDI TCK Issue Type: Bug Reporter: Marius Bogoevici The package contains a few tests that exercise deployment errors due to invalid intercepted class definitions. The tests must be separated (perhaps in individual packages) in order to make sure that the test cases run in isolation (since there are multiple sources of errors, the deployment will fail if at least one is satisfied, but we want to test all). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (CDITCK-224) Missing injection points for CircularDependencyTest

by Alexey Kazakov (JIRA)

Missing injection points for CircularDependencyTest --------------------------------------------------- Key: CDITCK-224 URL: https://issues.jboss.org/browse/CDITCK-224 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Alexey Kazakov It looks like that some beans tested by CircularDependencyTest miss injection points. See org.jboss.jsr299.tck.tests.lookup.circular.NormalSelfConsumingNormalProducer, org.jboss.jsr299.tck.tests.lookup.circular.DependentSelfConsumingNormalProducer, org.jboss.jsr299.tck.tests.lookup.circular.NormalSelfConsumingDependentProducer For instance there is a field *@SelfConsumingNormal1 Violation violation* in DependentSelfConsumingNormalProducer: {code} class DependentSelfConsumingNormalProducer { @SelfConsumingNormal1 Violation violation; @Produces @ApplicationScoped @SelfConsumingNormal1 public Violation produceViolation() { return new Violation(); } public void ping() { } } {code} which should be declared as an injection point: *@Inject* @SelfConsumingNormal1 Violation violation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

3
2
0 / 0

[JBoss JIRA] Created: (WELD-347) META-INF/beans.xml not sufficient to activate CDI in WAR

by Dan Allen (JIRA)

META-INF/beans.xml not sufficient to activate CDI in WAR -------------------------------------------------------- Key: WELD-347 URL: https://jira.jboss.org/jira/browse/WELD-347 Project: Weld Issue Type: Bug Components: GlassFish Integration Affects Versions: 1.0.0.GA Reporter: Dan Allen Assignee: Dan Allen Fix For: 1.0.1.CR1 In GlassFish V3, if a WAR is deployed containing WEB-INF/classes/META-INF/beans.xml, CDI does not get activated (no beans are detected). Activation only happens if the WAR contains WEB-INF/beans.xml. I'm not sure why GlassFish V3 is having a problem finding beans.xml in the META-INF directory of the WAR classpath. I can't tell if it is a problem in Weld or a problem in GlassFish V3 somewhere. -- 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

12 years, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (CDITCK-176) Decorator Elements in beans.xml use <decorator> not <class>

by Pete Muir (JIRA)

Decorator Elements in beans.xml use <decorator> not <class> ----------------------------------------------------------- Key: CDITCK-176 URL: https://jira.jboss.org/browse/CDITCK-176 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.2.CR2 Reporter: Pete Muir Fix For: 1.0.2.CR3 Affected tests: testPassivationCapableBeanWithNonPassivatingDecoratorBeanConstructorFails(org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingBeanConstructor.DecoratorWithNonPassivatingBeanConstructorTest) testPassivationCapableBeanWithNonPassivatingInitializerInDecoratorFails(org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInitializerMethod.DecoratorWithNonPassivatingInitializerMethodTest) testPassivationCapableBeanWithNonPassivatingDecoratorInjectedFieldFails(org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInjectedField.DecoratorWithNonPassivatingInjectedFieldTest) testEnterpriseBeanWithNonPassivatingDecoratorFails(org.jboss.jsr299.tck.tests.context.passivating.broken.enterpriseBeanWithNonPassivatingDecorator.EnterpriseBeanWithNonPassivatingDecoratorTest) testDecoratorListedTwiceInBeansXmlNotOK(org.jboss.jsr299.tck.tests.decorators.definition.broken.decoratorListedTwiceInBeansXml.DecoratorListedTwiceInBeansXmlTest) testNonExistantDecoratorClassInBeansXmlNotOK(org.jboss.jsr299.tck.tests.decorators.definition.broken.nonExistantClassInBeansXml.NonExistantDecoratorClassInBeansXmlTest) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (CDITCK-225) TCK needs a sig file recorded with Java SE 7

by Kyle Grucci (JIRA)

TCK needs a sig file recorded with Java SE 7 -------------------------------------------- Key: CDITCK-225 URL: https://issues.jboss.org/browse/CDITCK-225 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Signature Tests Affects Versions: 1.0.4.Final Environment: All Reporter: Kyle Grucci The TCK needs to be updated to also include a signature file which was recorded using Java SE 7 - http://www.java.net/download/openjdk/jdk7/promoted/b147/openjdk-7-fcs-src... http://download.java.net/openjdk/jdk7/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (CDITCK-227) Add a readme on github that points to the docs

by Jason Porter (JIRA)

Add a readme on github that points to the docs ---------------------------------------------- Key: CDITCK-227 URL: https://issues.jboss.org/browse/CDITCK-227 Project: CDI TCK Issue Type: Task Security Level: Public (Everyone can see) Reporter: Jason Porter -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues July 2011