[JBoss JIRA] Created: (JBSEAM-4658) <s:conversationPropagation> better validation of type parameter
by Andrew Wheeler (JIRA)
<s:conversationPropagation> better validation of type parameter
---------------------------------------------------------------
Key: JBSEAM-4658
URL: https://jira.jboss.org/browse/JBSEAM-4658
Project: Seam
Issue Type: Bug
Affects Versions: 2.2.1.CR1
Environment: JBoss AS M3
Reporter: Andrew Wheeler
The examples for <s:conversationPropagation> in section 7.1 of the documentation state that a nested conversation is started with type="nested". If used with a commandLink this causes handleConversationPropagation to begin a null pageflow. The result is that a NullPointerException is thrown.
Section 33.1.1.5 correctly states that type should be "nest".
I suggest that a check is performed on the conversationPropagation control to throw an exception if the wrong type is passed. The documentation should be corrected to be consistent.
--
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, 3 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3405) ClassCastException for Date passed in f:param
by Valerie Griffin (JIRA)
ClassCastException for Date passed in f:param
---------------------------------------------
Key: JBSEAM-3405
URL: https://jira.jboss.org/jira/browse/JBSEAM-3405
Project: Seam
Issue Type: Bug
Affects Versions: 2.0.3.CR1
Environment: ICEfaces 1.7.1, JBOSS 4.2.2, JDK 1.6
Reporter: Valerie Griffin
My seam-gen application has tables in which part of the key is a Date field. Therefore, its value is stuffed into an appropriate f:param when I click the Select s:link in the TblList.xhtml display. I get the following stack trace. If I change the code to remove the Date parameter, I do not get the stack trace. (Of course my code doesn't work without it.... I'm going to try wrapping the date in a String-based parameter with getter and setter as a workaround so I can get something working tomorrow.)
Exception during request processing:
Caused by javax.el.ELException with message: "java.lang.IllegalArgumentException: java.lang.ClassCastException@ccce74"
javax.el.BeanELResolver.setValue(BeanELResolver.java:116)
javax.el.CompositeELResolver.setValue(CompositeELResolver.java:68)
com.sun.faces.el.FacesCompositeELResolver.setValue(FacesCompositeELResolver.java:93)
org.jboss.el.parser.AstPropertySuffix.setValue(AstPropertySuffix.java:73)
org.jboss.el.parser.AstValue.setValue(AstValue.java:84)
org.jboss.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:249)
org.jboss.seam.core.Expressions$1.setValue(Expressions.java:116)
org.jboss.seam.navigation.Pages.applyConvertedValidatedValuesToModel(Pages.java:796)
org.jboss.seam.navigation.Pages.postRestore(Pages.java:409)
org.jboss.seam.jsf.SeamPhaseListener.postRestorePage(SeamPhaseListener.java:544)
org.jboss.seam.jsf.SeamPhaseListener.afterRestoreView(SeamPhaseListener.java:390)
org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:226)
org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:192)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:280)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
com.icesoft.faces.webapp.http.core.JsfLifecycleExecutor.apply(JsfLifecycleExecutor.java:17)
com.icesoft.faces.webapp.http.core.PageServer$1.respond(PageServer.java:25)
com.icesoft.faces.webapp.http.servlet.ServletRequestResponse.respondWith(ServletRequestResponse.java:161)
com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet$ThreadBlockingRequestResponse.respondWith(ThreadBlockingAdaptingServlet.java:36)
com.icesoft.faces.webapp.http.core.PageServer.service(PageServer.java:30)
com.icesoft.faces.webapp.http.core.SingleViewServer.service(SingleViewServer.java:48)
com.icesoft.faces.webapp.http.common.standard.PathDispatcherServer$Matcher.serviceOnMatch(PathDispatcherServer.java:50)
com.icesoft.faces.webapp.http.common.standard.PathDispatcherServer.service(PathDispatcherServer.java:19)
com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet.service(ThreadBlockingAdaptingServlet.java:19)
com.icesoft.faces.webapp.http.servlet.EnvironmentAdaptingServlet.service(EnvironmentAdaptingServlet.java:29)
com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet.service(MainSessionBoundServlet.java:139)
com.icesoft.faces.webapp.http.servlet.SessionDispatcher.service(SessionDispatcher.java:35)
com.icesoft.faces.webapp.http.servlet.PathDispatcher$Matcher.serviceOnMatch(PathDispatcher.java:52)
com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:29)
com.icesoft.faces.webapp.http.servlet.MainServlet.service(MainServlet.java:79)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
java.lang.Thread.run(Thread.java:619)
Caused by java.lang.IllegalArgumentException with message: "java.lang.ClassCastException@ccce74"
sun.reflect.GeneratedMethodAccessor5704.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
javax.el.BeanELResolver.setValue(BeanELResolver.java:108)
javax.el.CompositeELResolver.setValue(CompositeELResolver.java:68)
com.sun.faces.el.FacesCompositeELResolver.setValue(FacesCompositeELResolver.java:93)
org.jboss.el.parser.AstPropertySuffix.setValue(AstPropertySuffix.java:73)
org.jboss.el.parser.AstValue.setValue(AstValue.java:84)
org.jboss.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:249)
org.jboss.seam.core.Expressions$1.setValue(Expressions.java:116)
org.jboss.seam.navigation.Pages.applyConvertedValidatedValuesToModel(Pages.java:796)
org.jboss.seam.navigation.Pages.postRestore(Pages.java:409)
org.jboss.seam.jsf.SeamPhaseListener.postRestorePage(SeamPhaseListener.java:544)
org.jboss.seam.jsf.SeamPhaseListener.afterRestoreView(SeamPhaseListener.java:390)
org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:226)
org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:192)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:280)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
com.icesoft.faces.webapp.http.core.JsfLifecycleExecutor.apply(JsfLifecycleExecutor.java:17)
com.icesoft.faces.webapp.http.core.PageServer$1.respond(PageServer.java:25)
com.icesoft.faces.webapp.http.servlet.ServletRequestResponse.respondWith(ServletRequestResponse.java:161)
com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet$ThreadBlockingRequestResponse.respondWith(ThreadBlockingAdaptingServlet.java:36)
com.icesoft.faces.webapp.http.core.PageServer.service(PageServer.java:30)
com.icesoft.faces.webapp.http.core.SingleViewServer.service(SingleViewServer.java:48)
com.icesoft.faces.webapp.http.common.standard.PathDispatcherServer$Matcher.serviceOnMatch(PathDispatcherServer.java:50)
com.icesoft.faces.webapp.http.common.standard.PathDispatcherServer.service(PathDispatcherServer.java:19)
com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet.service(ThreadBlockingAdaptingServlet.java:19)
com.icesoft.faces.webapp.http.servlet.EnvironmentAdaptingServlet.service(EnvironmentAdaptingServlet.java:29)
com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet.service(MainSessionBoundServlet.java:139)
com.icesoft.faces.webapp.http.servlet.SessionDispatcher.service(SessionDispatcher.java:35)
com.icesoft.faces.webapp.http.servlet.PathDispatcher$Matcher.serviceOnMatch(PathDispatcher.java:52)
com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:29)
com.icesoft.faces.webapp.http.servlet.MainServlet.service(MainServlet.java:79)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
java.lang.Thread.run(Thread.java:619)
--
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, 3 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2286) MDB activated too early to use Seam components as a standard EJB
by Siarhei Dudzin (JIRA)
MDB activated too early to use Seam components as a standard EJB
----------------------------------------------------------------
Key: JBSEAM-2286
URL: http://jira.jboss.com/jira/browse/JBSEAM-2286
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 2.0.0.GA
Reporter: Siarhei Dudzin
Priority: Critical
As specified in the forum reference I have an MDB which uses a SLSB (also declared as Seam component) with business logic. If I deploy the application and there are already messages in the queue I get the following exception:
javax.ejb.EJBTransactionRolledbackException: java.lang.IllegalStateException: Attempted to invoke a
Seam component outside the an initialized application
at org.jboss.ejb3.tx.Ejb3TxPolicy.handleInCallerTx(Ejb3TxPolicy.java:87)
at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:130)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:249)
at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:268)
at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:138)
at $Proxy111.onMessage(Unknown Source)
Looks like the MDB processing the message before Seam is initialized?
This forces me to undeclare the SLSB as a Seam component and (potentially) duplicate business logic if I want to re-use the same functionality of the SLSB in Seam.
I could use the solution from http://www.jboss.org/?module=bb&op=viewtopic&t=100946 but then it would force me to use vendor-specific API.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] Created: (JBSEAM-4693) 6.12.2. Enabling Seam exception handling : web:exception-filter in components.xml
by simon lebettre (JIRA)
6.12.2. Enabling Seam exception handling : web:exception-filter in components.xml
---------------------------------------------------------------------------------
Key: JBSEAM-4693
URL: https://jira.jboss.org/browse/JBSEAM-4693
Project: Seam
Issue Type: Task
Components: Documentation Issues
Reporter: simon lebettre
this does not make sense :
"
6.12.2. Enabling Seam exception handling
To enable Seam's exception handling, we need to make sure we have the master servlet filter declared in web.xml:
"
==> Of course the master filter is in web.xml !
this would be more relevant :
"we need to make sure that <web:exception-filter url-pattern="*.seam" /> is declared in components.xml"
I m not being picky about the doc, it's been 7 months I have a bad user experience or loose some exception feedback because I forgot this line in components.xml !
--
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, 3 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4487) Concurrent requests; one invalidates the session, results in recursive loop of session creation
by dave atkins (JIRA)
Concurrent requests; one invalidates the session, results in recursive loop of session creation
-----------------------------------------------------------------------------------------------
Key: JBSEAM-4487
URL: https://jira.jboss.org/jira/browse/JBSEAM-4487
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.2.0.GA, 2.2.0.CR1, 2.1.2.GA, 2.1.2.CR2, 2.1.2.CR1, 2.1.1.GA
Environment: Jboss 4.2.2 with shipped Tomcat on Linux.
Reporter: dave atkins
I noticed that we had an massive number of sessions on one of our tomcat nodes that hosts our modest Seam app. After some investigation I discovered this in the log
2009-11-25 17:38:02,521 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.security.identity 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.security.identity 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session
This is repeated for thousands of lines. After digging around the seam code I realised that if you have two concurrent requests and one invalidates the session before the other is finished, seam goes into an recursive loop of session creation (normally ended by stack overflow). Here's a stack trace showing two recursions.
at org.jboss.seam.Component.newInstance(Component.java:2094)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209)
at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141)
at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
at org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189)
at org.jboss.seam.Component.getInstance(Component.java:1949)
at org.jboss.seam.Component.getInstance(Component.java:1944)
at org.jboss.seam.Component.getInstance(Component.java:1924)
at org.jboss.seam.Component.getInstance(Component.java:1919)
at org.jboss.seam.security.Identity.create(Identity.java:101)
at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
at org.jboss.seam.Component.callCreateMethod(Component.java:2134)
at org.jboss.seam.Component.newInstance(Component.java:2094)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209)
at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141)
at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
at org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189)
at org.jboss.seam.Component.getInstance(Component.java:1949)
at org.jboss.seam.Component.getInstance(Component.java:1944)
at org.jboss.seam.Component.getInstance(Component.java:1924)
at org.jboss.seam.Component.getInstance(Component.java:1919)
at org.jboss.seam.security.Identity.create(Identity.java:101)
at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
at org.jboss.seam.Component.callCreateMethod(Component.java:2134)
at org.jboss.seam.Component.newInstance(Component.java:2094)
This problem is partially documented here - https://jira.jboss.org/jira/browse/JBSEAM-2888, unfortunately this bugfix didn't solve the root cause of the problem.
The problem is caused by the SessionMap used by ServerConversationContext. Internally the session map uses HttpServletRequest.getSession(true) to retrieve the session, which creates a new session if the one defined on the HttpServletRequest is invalid or null. Unfortunately, when the new session is created session listeners are informed before the session has been set on the HttpServletRequest. Seam is one of these session listeners and creates a new Identity on session creation, which in turn accesses the SessionMap, still before the new Session has been set on the request. This leads to an infinite recursive loop.
The SessionMap used is returned by externalContext.getSessionMap(). One solution could be to implement our own SessionMap that doesn't attempt to create a new session if the current session is invalid or null, although I've no idea how this would impact on other Seam code.
The problem is relatively easy to create. In our application we have a search page that can take quite a while to complete a request. If we log out of the application in another tab before the search has completed the problem arises.
We are using seam 2.1.1.GA. I've looked at the source code for the latest release and it appears that the problem will still occur due to use of SessionMap.
Out current workaround is to add a ThreadLocal to Identity.create that counts recursive calls. If more then two recursive calls are detected an IllegalProcessState exception is thrown. This isn't definitely isn't a permanent solution, but stops our server creating 100,000 sessions.
--
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, 3 months