[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
[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
[JBoss JIRA] Created: (CDITCK-228) 2 CDI TCK Failures after latest Bean Validation integration into Java EE 6 RI
by Kyle Grucci (JIRA)
2 CDI TCK Failures after latest Bean Validation integration into Java EE 6 RI
-----------------------------------------------------------------------------
Key: CDITCK-228
URL: https://issues.jboss.org/browse/CDITCK-228
Project: CDI TCK
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tests
Affects Versions: 1.0.4.Final
Reporter: Kyle Grucci
This occurs in 1.0.4.SP3
As per recent discussions, we're trying to test a new Java EE 6 RI build with the latest Bean Validation code integrated. When we run the CDI TCK with it, we are now seeing the following errors. Any idea what the problem could be?
Tests
-------
org.jboss.jsr299.tck.tests.event.observer.enterprise.EnterpriseEventInheritenceTest testNonStaticObserverMethodIndirectlyInherited
org.jboss.jsr299.tck.tests.event.observer.enterprise.EnterpriseEventInheritenceTest testNonStaticObserverMethodInherited
1. org.jboss.jsr299.tck.tests.event.observer.enterprise.EnterpriseEventInheritenceTest testNonStaticObserverMethodIndirectlyInherited
javax.enterprise.event.ObserverException
at java.lang.Class.newInstance0(Class.java:372)
at java.lang.Class.newInstance(Class.java:325)
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40)
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:92)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:214)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:622)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:616)
at org.jboss.jsr299.tck.tests.event.observer.enterprise.EnterpriseEventInheritenceTest.testNonStaticObserverMethodIndirectlyInherited(EnterpriseEventInheritenceTest.java:55)
at org.jboss.testharness.AbstractTest.run(AbstractTest.java:244)
at org.jboss.testharness.impl.runner.TestRunner.run(TestRunner.java:61)
at org.jboss.testharness.impl.runner.servlet.ServletTestRunner.doGet(ServletTestRunner.java:120)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.IllegalAccessError: tried to access class org.jboss.jsr299.tck.tests.event.observer.enterprise.StockPrice from class org.jboss.jsr299.tck.tests.event.observer.enterprise.StockWatcherLocal$1879483017$Proxy$_$$_Weld$Proxy$
at org.jboss.jsr299.tck.tests.event.observer.enterprise.StockWatcherLocal$1879483017$Proxy$_$$_Weld$Proxy$.observeStockPrice(StockWatcherLocal$1879483017$Proxy$_$$_Weld$Proxy$.java)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
... 63 more
... Removed 42 stack frames
2. org.jboss.jsr299.tck.tests.event.observer.enterprise.EnterpriseEventInheritenceTest testNonStaticObserverMethodInherited
javax.enterprise.event.ObserverException
at java.lang.Class.newInstance0(Class.java:372)
at java.lang.Class.newInstance(Class.java:325)
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40)
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:92)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:214)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:622)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:616)
at org.jboss.jsr299.tck.tests.event.observer.enterprise.EnterpriseEventInheritenceTest.testNonStaticObserverMethodInherited(EnterpriseEventInheritenceTest.java:44)
at org.jboss.testharness.AbstractTest.run(AbstractTest.java:244)
at org.jboss.testharness.impl.runner.TestRunner.run(TestRunner.java:61)
at org.jboss.testharness.impl.runner.servlet.ServletTestRunner.doGet(ServletTestRunner.java:120)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.IllegalAccessError: tried to access class org.jboss.jsr299.tck.tests.event.observer.enterprise.Egg from class org.jboss.jsr299.tck.tests.event.observer.enterprise.FarmerLocal$LazyFarmerLocal$637225338$Proxy$_$$_Weld$Proxy$
at org.jboss.jsr299.tck.tests.event.observer.enterprise.FarmerLocal$LazyFarmerLocal$637225338$Proxy$_$$_Weld$Proxy$.observeEggLaying(FarmerLocal$LazyFarmerLocal$637225338$Proxy$_$$_Weld$Proxy$.java)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
... 63 more
... Removed 42 stack frames
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[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
[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
[JBoss JIRA] Created: (WELD-959) Weld SE should support modular bean declaration archives, and bean sharing
by Lincoln Baxter III (JIRA)
Weld SE should support modular bean declaration archives, and bean sharing
--------------------------------------------------------------------------
Key: WELD-959
URL: https://issues.jboss.org/browse/WELD-959
Project: Weld
Issue Type: Feature Request
Components: Java SE Support
Affects Versions: 1.1.2.Final
Environment: JBoss Modules 1.0.1.Final
Reporter: Lincoln Baxter III
When booting weld SE in a modular environment (JBoss Modules), it currently takes the TCCL and scans all beans it can find; however, there is no concept of a modular structure between these beans. Take Forge, for instance:
Forge (A beans archive) bundles Seam Render, a templating library, for use in rendering various types of output. Seam Render is also a Beans Archive.
When a forge Plugin (also a Beans archive) includes Seam Render, now there is a conflict. What *should* happen, is that Weld uses Seam Render beans from the archive bundled with Forge's modules, for forge, and uses the Render beans bundled in the plugin's modules, for the plugin. What actually happens is that weld throws an "Unsatisfied injection point" exception.
If the plugin is compiled against the Seam Render JAR, but does not bundle it (provided scope,) then a ClassNotFoundException is thrown.
It should be possible to share beans across modules properly in Weld SE.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] Created: (WELD-956) Outside the VPN it's impossible to build weld from source with an empty maven repository because repository.jboss.org/maven2 is forbidden
by Geoffrey De Smet (JIRA)
Outside the VPN it's impossible to build weld from source with an empty maven repository because repository.jboss.org/maven2 is forbidden
-----------------------------------------------------------------------------------------------------------------------------------------
Key: WELD-956
URL: https://issues.jboss.org/browse/WELD-956
Project: Weld
Issue Type: Task
Reporter: Geoffrey De Smet
Priority: Optional
To reproduce:
- Disconnect from the VPN
- rm -Rf ~/.m2/repository/apache-log4j/
- clone https://github.com/weld/core as weld-core
- cd weld-core
- mvn clean install -DskipTests
result:
{code}
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 20.507s
[INFO] Finished at: Mon Aug 29 14:02:33 CEST 2011
[INFO] Final Memory: 27M/492M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project weld-core-test: Could not resolve dependencies for project org.jboss.weld:weld-core-test:jar:1.1.3-SNAPSHOT: Failed to collect dependencies for [org.testng:testng:jar:jdk15:5.10 (compile), org.jboss.test-harness:jboss-test-harness:jar:1.1.0-CR9 (compile), org.jboss.test-harness:jboss-test-harness-jboss-as-60:jar:1.1.0-CR9 (test), javax.el:el-api:jar:2.2 (compile), org.glassfish.web:el-impl:jar:2.1.2-b04 (compile), org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar:1.0.0.Beta2 (compile), org.jboss.weld:weld-core:jar:1.1.3-SNAPSHOT (compile), org.jboss.weld:weld-spi:jar:1.1.Beta2 (compile), org.jboss.weld:weld-api:jar:1.1.Beta2 (compile), org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:jar:1.0.0.Beta1 (compile), org.jboss.interceptor:jboss-interceptor-spi:jar:2.0.0.CR1 (compile), org.jboss.interceptor:jboss-interceptor-core:jar:2.0.0.CR1 (compile), org.jboss.spec.javax.ejb:jboss-ejb-api_3.1_spec:jar:1.0.0.CR2 (compile), org.slf4j:slf4j-simple:jar:1.5.10 (test), javax.transaction:jta:jar:1.1 (compile), javax.persistence:persistence-api:jar:1.0 (compile), javax.validation:validation-api:jar:1.0.0.GA (compile), javax.faces:jsf-api:jar:2.0.2-FCS (compile), net.sourceforge.htmlunit:htmlunit:jar:2.4 (compile), org.jboss.weld.arquillian.container:arquillian-weld-ee-embedded-1.1:jar:1.1.3-SNAPSHOT (provided)]: Failed to read artifact descriptor for apache-log4j:log4j:jar:1.2.14: Could not transfer artifact apache-log4j:log4j:pom:1.2.14 from/to repository.jboss.org (http://repository.jboss.org/maven2/): Access denied to: http://repository.jboss.org/maven2/apache-log4j/log4j/1.2.14/log4j-1.2.14... -> [Help 1]
{code}
Why? Inside the VPN you can connect to
http://repository.jboss.org/maven2/apache-log4j/log4j/1.2.14/log4j-1.2.14...
But outside the VPN you get "FORBIDDEN" instead for that url.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months