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). So it's the jsf-impl which has changed that leads to this error. However, the real questions are: 1) Should (EJB) *deployments* be listed in the MANIFEST.MF files of other deployments. In this example the jboss-seam.jar which is a EJB deployment (marked as a "module" in application.xml) is listed in MANIFEST.MF of an xxx-ejb.jar deployment. 2) Is the duplicate temp files for the same jar file (jboss-seam.jar) intentional? It's created once during the MANIFEST.MF parsing of xxx-ejb.jar deployment and once during deploying jboss-seam.jar deployment (which is listed as a module in application.xml). -------------------- Archived deployment : -------------------- When the application is deployed as an archive, the deployment framework creates a exploded temp of the EAR in the tmp folder. It however does *not* create temps for the sub-deployments or the libraries within the ear. So there is only one jboss-seam.jar in tmp/sometmpName.ear-contents. Because of this the logic explained above, registers the SeamPhaseListener only once and hence no issues. Max Rydahl Andersen wrote: Because of the logic involved in the deployment framework (see above) Though the JIRA mentions this, i don't see a reason why the name should matter. I did not see any other explanation in the JIRA as to how this fixed the issue. Is there some app which shows this behaviour? Because of the duplicate temp jars that are created during deployment process, when Manifest.mf is involved (see above explanation). regards, -Jaikiran

Max Rydahl Andersen wrote: I agree, adding it to the MANIFEST.MF should not be breaking the deployment. Someone who knows better about JBoss-4.x deployers would probably know how to fix this. Luckily yes :) I looked at what the MainDeployer[1] does. The important piece of code is : private void parseManifestLibraries(DeploymentInfo sdi) { ...//blah blah blah if (classPath != null) { StringTokenizer st = new StringTokenizer(classPath); log.debug("resolveLibraries: "+classPath); while (st.hasMoreTokens()) { ...//blah blah blah // Only deploy this if it is not already being deployed if ( deploymentMap.containsKey(lib) == false ) { /* Test that the only deployer for this is the JARDeployer. Any other type of deployment cannot be initiated through a manifest reference. */ DeploymentInfo mfRef = new DeploymentInfo(lib, null, getServer()); makeLocalCopy(mfRef); URL[] localURL = {mfRef.localUrl}; mfRef.localCl = new java.net.URLClassLoader(localURL); findDeployer(mfRef); SubDeployer deployer = mfRef.deployer; if(deployer != null && (deployer instanceof JARDeployer) == false) { // Its a non-jar deployment that must be deployed seperately log.warn("Found non-jar deployer for " + tk + ": " + deployer); } // add the library sdi.addLibraryJar(lib); } } So, if the classpath entry contains a reference to a jar which is *already being deployed*, then it will *not* create a (duplicate) temp copy while parsing the manifest entry. The (single) temp copy will be created when the deployment jar (marked as module in application.xml) is being processed for deployment. So the *workaround* is to ensure that deployments which are referenced in Classpath attribute of other deployments are deployed first. For ex: in the application attached to the JIRA, the xxx-ejb.jar refers to jboss-seam.jar (EJB deployment) in the MANIFEST.MF. So the trick is to ensure that jboss-seam is picked up for deployment before xxx-ejb.jar is picked for deployment (and the subsequent MANIFEST.MF processing). This can be done by specifying the correct order of modules in the application.xml and *also* specifying the module-order as "strict" in jboss-app.xml (by default the module-order is "implicit" which follows filename based deployment ordering [2]). So here's what i did: application.xml: <?xml version="1.0" encoding="UTF-8"?> <application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd" version="5"> <display-name>xxx-ear</display-name> <!-- JBIDE-4166 Workaround - Make sure we deploy this first, since this is referenced in xxx-ejb.jar--> <module> <ejb>jboss-seam.jar</ejb> </module> <module> <ejb>xxx-ejb.jar</ejb> </module> <module> <web> <web-uri>xxx.war</web-uri> <context-root>/xxx</context-root> </web> </module> </application> jboss-app.xml: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD J2EE Application 4.2//EN" "http://www.jboss.org/j2ee/dtd/jboss-app_4_2.dtd"> <jboss-app> <!-- JBIDE-4166 : We need strict ordering to follow the order mentioned in application.xml --> <module-order>strict</module-order> <loader-repository> seam.jboss.org:loader=xxx-ear.ear </loader-repository> </jboss-app> So all that JBoss Tools needs to do is add a intelligent ordering of the modules in the application.xml and mark the application for strict module ordering in the jboss-app.xml. [1] http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_4_2_3_GA/system/src/mai... [2] This also explains why the deployment behaves differently when the name of the deployment is changed. Not sure. Someone who has more experience on the 4.x deployers might know. When i read the JIRA, i thought the user was noting that changing the name of the EAR fixed the issue. That's why i commented that naming of the files should not matter (atleast for this specific issue). However after what i explained above, related to implicit ordering of deployments *within* an EAR, i think the user was talking about renaming the deployments *within* the EAR. That makes sense now and it definitely affects (= is expected) the deployment ordering. -Jaikiran