[jbosstools-issues] [JBoss JIRA] Commented: (JBIDE-4166) Seam Web EAR project using Seam 2.1.1.GA does not work on JBoss AS 4.2.3

[ https://jira.jboss.org/jira/browse/JBIDE-4166?page=com.atlassian.jira.plu... ] Max Rydahl Andersen commented on JBIDE-4166: -------------------------------------------- Here is the explanation of why it is occurring: This issue (the WARN message that SeamPhaseListener spits out and ultimately the application isn't accessible), has come up frequently in user forums but has ended up without any clean solutions. I just tried out the application attached to the JBIDE-4166 JIRA and here's what causes this issue: Exploded deployment: -------------------- 4.2.2 - The deployment framework: -------------------- 1) During deploy, it picks up the EAR/xxx-ejb.jar. Looks at its Manifest.mf and finds jboss-seam listed. So creates a tmp out of this and puts it in the tmp folder and adds it to classpath of the app. Let's call this temped file as tmpAjboss-seam.jar. 2) Later on during deploy, it picks up EAR/jboss-seam.jar (since its listed as a module in application.xml) and creates a temp jar out of this and adds to classpath of the app. Let's call this temped file as tmpBjboss-seam.jar. 3) Ultimately, we now have 2 (duplicated) temp versions of the same jboss-seam jar file. 4) Later on during the servlet context initialization of the seam application, the com.sun.faces.config.ConfigListener.contextInitialized (from jsf-impl.jar available in the AS) gets all META-INF/faces-config.xml resources in the application's classpath. This URL list now contains tmpAjboss-seam.jar and tmpBjboss-seam.jar (the duplicated temp versions of jboss-seam.jar). 5) Then the xmls corresponding to these URLs are parsed corresponding LifecycleBean(s) are created out of these. 6) The phase listeners (ex: SeamPhaseListener) are then added to a list maintained in com.sun.faces.config.beans.LifecycleBean. However, before adding the LifecycleBean does a check for phase listeners already registered with the given name. If present, then it *ignores* the next phase listener with the same name: public void addPhaseListener(String phaseListener) { if (!(this.phaseListeners.contains(phaseListener))) { ...// some logic this.phaseListeners.add(phaseListener); } } Ultimately, each of these phaseListeners are instantiated and invoked. Because of this logic involved in the LifecycleBean, the SeamPhaseListener is registered only once, even though 2 (duplicate temp) jars with faces-config.xml contained this listener. In 4.2.3 - The jsf-impl.jar version is different and the classes have been refactored. But the logic involved is the same till step#4 above. In the later steps, the call goes to com.sun.faces.config.processor.LifecycleProcessor. Here there is no check for existing phaseListeners with the same name. As a result, the SeamPhaseListener is instantiated twice which leads to it complaining: 15:40:49,386 WARN [SeamPhaseListener] There should only be one Seam phase listener per application Ultimately this leads to an exception while accessing the application (which i believe is related to the incorrect phase listener coming into picture). -- 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