Hide Forgot
When an additional JSF slot was installed in the root of the `modules` directory, the 'main' JSF slot was not added as a valid JSF configuration. Deploying a JSF application that attempted to use the 'main' JSF implementation would fail with the message: ---- org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS012656: Default JSF implementation slot 'main' is invalid ---- The cause of this issue has been resolved and the "main" slot is now always considered to be one of the valid JSF implementations. As a result, when an additional JSF slot is added in the root of the `modules` directory, JSF applications that make use of the 'main' JSF implementation instead can be successfully deployed.
Suppose following additional slot JSF configuration: modules/com/ `-- sun `-- jsf-impl `-- mojarra-2.2.4 |-- jsf-impl-2.2.4-jbossorg-1.jar |-- module.xml modules/javax/ `-- faces `-- api `-- mojarra-2.2.4 |-- jboss-jsf-api_2.2_spec-2.2.4.jar |-- module.xml When you start server having following configuration: <subsystem xmlns="urn:jboss:domain:jsf:1.0"/> you won't be able to deploy any JSF application, since the default "main" version is not handled correctly in org.jboss.as.jsf.deployment.JSFModuleIdFactory. Note that this version is added only in "loadIdsManually" method, which is never called in this case. This results to: 7:55:20,542 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."weld-numberguess.war".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."weld-numberguess.war".DEPENDENCIES: JBAS018733: Failed to process phase DEPENDENCIES of deployment "weld-numberguess.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS012656: Default JSF implementation slot 'main' is invalid at org.jboss.as.jsf.deployment.JSFDependencyProcessor.deploy(JSFDependencyProcessor.java:78) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] ... 5 more
I haven't been able to reproduce this with EAP 6.2. Please provide some more information on how to do this. Please also attach your mojarra-2.2.4 module.xml files and the JSF application you're trying to deploy. Thanks.
Created attachment 855978 [details] optional jsf structure Hi Farah! IMHO It's not problem of module.xml content, but wrong org.jboss.as.jsf.deployment.JSFDependencyProcessor. Anyway you can extract the attached zip (containing mojarra-2.2.4 structure with jars and xml config) to your $JBOSS_HOME/modules, start your server and try to deploy any application using JSF.
Thanks, Tomas. I was able to reproduce the issue. The problem is that when a JSF implementation is installed in the root of the modules directory, the "main" implementation will no longer get added as a valid JSF configuration. This bug was fixed in WildFly by making sure that "main" is always considered to be one of the valid JSF implementations (see https://github.com/wildfly/wildfly/pull/4425). We'll need to apply this fix to the jboss-eap repo as well.
Verified in 6.3.0.DR0
Attention: Farah Thank you for excellent "Doc Text". I had to do very little editing. Your help in making my job easier is very much appreciated.
I have EAP 6.2 but I am getting the same issue. When I add the default impl slot, it says it is invalid. Please help.
Please read properly this issue. This was fixed in first releases of EAP 6.3, so this is definitely broken in 6.2. See version and target release fields of this issue.
*** Bug 1122875 has been marked as a duplicate of this bug. ***