[jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-1556) Multiple instances of Seam PhaseListener permitted to be registered in JSF lifecycle

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 Attachments: AbstractSeamPhaseListener.java, SeamPhaseListener.java, SeamPortletPhaseListener.java 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.