April 2011 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-799) Weld throws java.lang.IllegalStateException: Context is not active during stress testing at higher number of clients

by Martin Gencur (JIRA)

Weld throws java.lang.IllegalStateException: Context is not active during stress testing at higher number of clients -------------------------------------------------------------------------------------------------------------------- Key: WELD-799 URL: https://issues.jboss.org/browse/WELD-799 Project: Weld Issue Type: Bug Components: Performance and Scalability Affects Versions: 1.1.0.CR1 Environment: JBossAS 6 CR1, Weld/trunk Reporter: Martin Gencur Fix For: 1.1.0.Final I executed performance stress test using Wicket for view layer and Weld-trunk. Everything goes well up to 2100 sessions. Then the following exception is thrown. I tried it twice and it failed at the same amount of sessions. Whole stack trace: 2010-12-17 03:03:57,840 WARN [org.apache.wicket.protocol.http.pagestore.FileChannelPool] (http-10.16.89.196-8080-304) Unable to reduce enough channels, no idle channels left to remove. 2010-12-17 03:03:57,842 WARN [org.apache.wicket.protocol.http.pagestore.FileChannelPool] (PageSavingThread-Wicket Filter) Unable to reduce enough channels, no idle channels left to remove. 2010-12-17 03:03:57,842 WARN [org.apache.wicket.protocol.http.pagestore.FileChannelPool] (PageSavingThread-Wicket Filter) Unable to reduce enough channels, no idle channels left to remove. 2010-12-17 03:03:58,499 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/seam-wicket-examples-numberguess-3.0.0-SNAPSHOT]] (http-10.16.89.196-8080-6) Exception sending request destroyed lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: Context is not active at org.jboss.weld.context.AbstractConversationContext.deactivate(AbstractConversationContext.java:263) [:2010-12-17 02:45] at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:125) [:2010-12-17 02:45] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:204) [:6.0.0.20101110-CR1] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.20101110-CR1] at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.Final] at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.Final] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.20101110-CR1] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.20101110-CR1] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.20101110-CR1] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.20101110-CR1] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.20101110-CR1] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.20101110-CR1] at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.20101110-CR1] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.20101110-CR1] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.0.0.20101110-CR1] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [:6.0.0.20101110-CR1] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.20101110-CR1] at java.lang.Thread.run(Thread.java:619) [:1.6.0_20] There is a new hudson job which tests this at http://hudson.qa.jboss.com/hudson/view/Weld/job/perf-seam-wicket-numbergu... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

4
5
0 / 0

[JBoss JIRA] Created: (WELD-809) NPE in ForwardingContextual.toString during session failover

by Sivakumar Thyagarajan (JIRA)

NPE in ForwardingContextual.toString during session failover ------------------------------------------------------------ Key: WELD-809 URL: https://issues.jboss.org/browse/WELD-809 Project: Weld Issue Type: Bug Reporter: Sivakumar Thyagarajan Please see the corresponding GlassFish issue for more information http://java.net/jira/browse/GLASSFISH-15277 GlassFish SQE has a multi-machine HA cluster setup, where during session failover of a shopping cart sample application, the following NPE is thrown is ForwardingContextual.toString java.lang.NullPointerException at org.jboss.weld.context.ForwardingContextual.toString(ForwardingContextual.java:53) at java.lang.String.valueOf(String.java:2826) at java.lang.StringBuilder.append(StringBuilder.java:115) at org.jboss.weld.context.SerializableContextualInstanceImpl.toString(SerializableContextualInstanceImpl.java:66) at java.lang.String.valueOf(String.java:2826) at java.lang.StringBuilder.append(StringBuilder.java:115) at org.jboss.weld.context.beanstore.AttributeBeanStore.attach(AttributeBeanStore.java:120) at org.jboss.weld.context.AbstractBoundContext.activate(AbstractBoundContext.java:75) at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:138) at org.apache.catalina.core.StandardContext.fireRequestInitializedEvent(StandardContext.java:4544) at org.apache.catalina.core.StandardHostValve.preInvoke(StandardHostValve.java:626) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:323) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

5
5
0 / 0

[JBoss JIRA] Created: (WELD-879) Tomcat 7 container is identified as Tomcat 6

by Ashley Westwell (JIRA)

Tomcat 7 container is identified as Tomcat 6 -------------------------------------------- Key: WELD-879 URL: https://issues.jboss.org/browse/WELD-879 Project: Weld Issue Type: Bug Components: CDI API Affects Versions: 1.1.1.Final Environment: Tomcat 7.0.11 Reporter: Ashley Westwell Weld-servlet 1.1.1-Final identifies tomcat 7 as tomcat 6 environment.In Listener.java it executes the following code container = checkContainers(cc, dump, Arrays.asList( Tomcat6Container.INSTANCE, Tomcat7Container.INSTANCE, Jetty6Container.INSTANCE, Jetty7Container.INSTANCE, JettyPost72Container.INSTANCE) ); This method returns a Tomcat6Container as Tomcat 7.0.11 at least has the class org.apache.catalina.core.ApplicationContextFacade. I would suggest reversing the order to have Tomcat7Container checked first as I from my knowledge the class org.apache.tomcat.InstanceManager is new to Tomcat 7 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

3
4
0 / 0

[JBoss JIRA] Created: (WELD-886) AbstractContext creationLock deadlock

by MIchail Nikolaev (JIRA)

AbstractContext creationLock deadlock ------------------------------------- Key: WELD-886 URL: https://issues.jboss.org/browse/WELD-886 Project: Weld Issue Type: Bug Affects Versions: 1.1.1.Final Environment: glassfish Reporter: MIchail Nikolaev AbstractContext.creationLock same for all applications on same server. I have portlet and webservice deployed on same glassfish server. On start of portlet the call to managed bean (@ApplicationScoped) is occured (FolderService.getRootFolder). It causes to lock creationLock in AbstractContext, create instance for bean, then call getRootFolder as default postconstruct method. After getRootFolder calls webservice deployed on the same server. Webservice method access another @ApplicationScoped bean. It causes to lock creationLock again (in another thread) and produces deadlock. Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

4
4
0 / 0

[JBoss JIRA] Created: (WELD-888) Interceptors not resolvable from a WAR-module which is part of an EAR-deployment

by Jan Groth (JIRA)

Interceptors not resolvable from a WAR-module which is part of an EAR-deployment -------------------------------------------------------------------------------- Key: WELD-888 URL: https://issues.jboss.org/browse/WELD-888 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.1.1.Final Environment: - Weld 1.1.1. Final on JBoss 6.0 GA and JBoss 6.1 nightly - tested and confirmed on Vista 32 and Linux 64 Reporter: Jan Groth It seems like CDI interceptors cannot be accessed from inside a WAR-module of an EAR deployment if the interceptor is defined inside a dependent JAR which is located in the EAR/lib directory. BUT: - Managed beans and producers from the same JAR work without problems. - Moving the dependency from EAR/lib to WAR/WEB-INF/lib makes the interceptor work without problems. I consider that a serious problem, because this is a substantial restriction for enterprise applications. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

5
9
0 / 0

[JBoss JIRA] Created: (WELD-851) Upgrade to findbugs-maven-plugin 2.3.2 when available

by Jozef Hartinger (JIRA)

Upgrade to findbugs-maven-plugin 2.3.2 when available ----------------------------------------------------- Key: WELD-851 URL: https://issues.jboss.org/browse/WELD-851 Project: Weld Issue Type: Task Components: Testing Infrastructure (Mocks and Harness Integration) Affects Versions: 1.1.0.Final Reporter: Jozef Hartinger Priority: Minor Upgrade to findbugs-maven-plugin 2.3.2 when available. Due to MFINDBUGS-122 it is not currently possible to run findbugs analysis. http://jira.codehaus.org/browse/MFINDBUGS-122 https://hudson.qa.jboss.com/hudson/view/Weld/job/Weld-trunk-findbugs/399/ -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
4
0 / 0

[JBoss JIRA] Created: (WELD-764) Instance appears to leak memory

by Pete Muir (JIRA)

Instance appears to leak memory ------------------------------- Key: WELD-764 URL: https://jira.jboss.org/browse/WELD-764 Project: Weld Issue Type: Bug Reporter: Pete Muir Fix For: 1.1.0.CR1 Nothing formal to confirm this, just a feeling from looking at a few problems -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (WELD-415) testApplicationScopeActiveDuringCallToEjbTimeoutMethod TCK test method is failing in Hudson

by Martin Gencur (JIRA)

testApplicationScopeActiveDuringCallToEjbTimeoutMethod TCK test method is failing in Hudson ------------------------------------------------------------------------------------------- Key: WELD-415 URL: https://jira.jboss.org/jira/browse/WELD-415 Project: Weld Issue Type: Bug Components: Testing Infrastructure (Mocks and Harness Integration) Affects Versions: 1.0.1.CR1 Reporter: Martin Gencur Assignee: Pete Muir Fix For: 1.0.1.CR2 Stack trace: java.lang.AssertionError at org.jboss.jsr299.tck.tests.context.application.ejb.EJBApplicationContextTest.testApplicationScopeActiveDuringCallToEjbTimeoutMethod(EJBApplicationContextTest.java:31) -- 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

13 years, 5 months

3
5
0 / 0

[JBoss JIRA] Created: (WELD-823) Injection into Servlet not working in Jetty 6.x

by Dan Allen (JIRA)

Injection into Servlet not working in Jetty 6.x ----------------------------------------------- Key: WELD-823 URL: https://issues.jboss.org/browse/WELD-823 Project: Weld Issue Type: Bug Components: Web Tier integration (JSF, JSP, EL and Servlet) Affects Versions: 1.1.0.CR4 Reporter: Dan Allen Fix For: 1.1.0.Final Apparently the test suite does not test injection into Servlets for Jetty 6.x because users are reporting that it doesn't work. I added a Servlet injection into the numberguess example and was able to verify that the injection is not taking place, despite receiving the startup message: INFO: Jetty detected, JSR-299 injection will be available in Servlets and Filters. Injection into Listeners is not supported. If this turns out to be a user error, then we need to turn to a documentation improvement, because a guy like Antonio should not be having difficulty getting this to work. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

5
16
0 / 0

[JBoss JIRA] Created: (WELD-849) Change vendor from sfwk.org to Red Hat for Weld artifacts

by Shane Bryzak (JIRA)

Change vendor from sfwk.org to Red Hat for Weld artifacts --------------------------------------------------------- Key: WELD-849 URL: https://issues.jboss.org/browse/WELD-849 Project: Weld Issue Type: Task Reporter: Shane Bryzak Assignee: Ales Justin I believe this comes from the <organization> tag in the weld-core-parent module. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues April 2011