[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1739) EmptyStackException in Transaction.java
by Florian Bartels (JIRA)
EmptyStackException in Transaction.java
---------------------------------------
Key: JBSEAM-1739
URL: http://jira.jboss.com/jira/browse/JBSEAM-1739
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 2.0.0.BETA1
Environment: Seam CVS 2007 07 28
Reporter: Florian Bartels
I still get the bug as in JBSEAM-1696. The recent changes do not seem to affect this problem. I was not able to identify another problem.
Here is the stack trace:
java.lang.IllegalStateException: Could not commit transaction
at org.jboss.seam.jsf.SeamPhaseListener.commitOrRollback(SeamPhaseListener.java:591)
at org.jboss.seam.jsf.SeamPhaseListener.handleTransactionsAfterPhase(SeamPhaseListener.java:325)
at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:226)
at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:184)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:280)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
at com.icesoft.faces.webapp.http.core.ReceiveSendUpdates.renderCycle(ReceiveSendUpdates.java:57)
at com.icesoft.faces.webapp.http.core.ReceiveSendUpdates.service(ReceiveSendUpdates.java:45)
at com.icesoft.faces.webapp.http.core.IDVerifier.service(IDVerifier.java:25)
at com.icesoft.faces.webapp.http.servlet.BasicAdaptingServlet.service(BasicAdaptingServlet.java:16)
at com.icesoft.faces.webapp.http.servlet.ViewBoundAdaptingServlet.service(ViewBoundAdaptingServlet.java:44)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher$Matcher.serviceOnMatch(PathDispatcher.java:52)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:29)
at com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet.service(MainSessionBoundServlet.java:97)
at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.service(SessionDispatcher.java:35)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher$Matcher.serviceOnMatch(PathDispatcher.java:52)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:29)
at com.icesoft.faces.webapp.http.servlet.MainServlet.service(MainServlet.java:85)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:469)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:364)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
at com.icesoft.faces.webapp.xmlhttp.BlockingServlet.service(BlockingServlet.java:54)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:82)
at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:68)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:68)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:68)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:44)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:68)
at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:127)
at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:277)
at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:68)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:68)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:149)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.util.EmptyStackException
at java.util.Stack.peek(Stack.java:79)
at org.jboss.seam.transaction.SeSynchronizations.beforeTransactionCommit(SeSynchronizations.java:50)
at org.jboss.seam.transaction.UTTransaction.commit(UTTransaction.java:49)
at org.jboss.seam.jsf.SeamPhaseListener.commitOrRollback(SeamPhaseListener.java:581)
... 62 more
--
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
16 years, 8 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1720) s:link doesnt work correctly in a portlet
by Chris Rudd (JIRA)
s:link doesnt work correctly in a portlet
-----------------------------------------
Key: JBSEAM-1720
URL: http://jira.jboss.com/jira/browse/JBSEAM-1720
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
When using a s:link inside a portlet application the actionMethod/etc are not properly processed.
Ive traced this down, the current SeamPhaseListener processes pageActions and the s:link/s:button as part of the beforeRender processing. The actionMethod/actionOutcome/etc parameters are only passed to the portlet during the processAction portlet request. The beforeRender is executed during the doView portlet request, which doesnt have access to those parameters.
One possible solution is to pass those parameters as renderparameters via the SeamPhaseListener.setPortletRenderParameter so that they are accessible to the doView render process.
I think the better solution is to have all that processing occur during the processAction phase instead of the doView phase.
The following change seems to work :
SeamPhaseListener.afterPortletPhase line 258
+ // Use the getRenderResponse flag to indicate that we have hit the end of the last phase that will
+ // be processed before the render. Handle the beforeRender at this time, as the next phase to
+ // occur should be RENDER_RESPONSE
+ if( event.getPhaseId() != RENDER_RESPONSE && facesContext.getRenderResponse() )
+ beforeRender(event);
+
FacesMessages.afterPhase();
After this change (and JBSEAM-1719) s:link/s:button works under jboss-portal 2.6
--
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
16 years, 8 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1556) Multiple instances of Seam PhaseListener permitted to be registered in JSF lifecycle
by Neil Griffin (JIRA)
Multiple instances of Seam PhaseListener permitted to be registered in JSF lifecycle
------------------------------------------------------------------------------------
Key: JBSEAM-1556
URL: http://jira.jboss.com/jira/browse/JBSEAM-1556
Project: JBoss Seam
Issue Type: Bug
Components: JSF
Affects Versions: 1.2.1.GA
Environment: WinXP / Liferay 4.3.0 / Tomcat 6.0.13
Reporter: Neil Griffin
Background: I found this problem when trying to package-up the Seam "Registration" example as a portlet under Liferay Portal.
The AbstractSeamPhaseListener class has a nice warning in the constructor, which alerts you in case more than one Seam-related PhaseListener is registered in the JSF lifecycle:
private static boolean exists = false;
protected AbstractSeamPhaseListener()
{
if (exists) log.warn("There should only be one Seam phase listener per application");
exists=true;
}
While this is good and helpful, the code needs to be improved to ENSURE that only one Seam-related PhaseListener is permitted to execute.
Case in point: When running in a portlet environment and using MyFaces, JSF PhaseListeners get registered TWICE, due to the way MyFaces initializes itself:
1. MyFaces has a StartupServletContextListener that initializes the JSF framework (the first time).
2. The MyFacesGenericPortlet.initMyFaces() method initializes the JSF framework (a second time).
Normally this would not be a big deal, but Seam has a restriction such that only one Seam-related PhaseListener may be active in the JSF Lifecycle. Because of the double-initialization that MyFaces is performing in the portlet scenario, any <phase-listener> elements found in the faces-config.xml file get registered twice! In Seam, this can cause all kinds of runtime problems.
There are two ways that I can think of to fix this:
1. Only let the first PhaseListener "win", and prevent any others from executing their phase handler callbacks (even though registered in the JSF lifecycle).
2. Unregister PhaseListeners that don't win. This is hard to do though -- it can't be done in the constructor, because the PhaseListener can't unregister itself at that time, because it hasn't been added to the lifecycle yet.
2.
--
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
16 years, 8 months