7 Replies Latest reply on Mar 29, 2011 9:03 PM by chriskulinski

    Running Two Mojarra config in single ear

    jgautier

      Hi,

       

      I've got an ear with the following structure:

       

      myear.ear

            |-->lib

            |-->mywar1.war

                     |-->WEB-INF

                          jboss-classloading.xml         

                          |-->lib    

                               |-->richfaces3*.jar

                               |-->seam-2.2.*.jar

            |-->mywar2.war

                     |-->WEB-INF

                          jboss-classloading.xml

                          |-->lib

                               |-->richfaces4*.jar

                               |-->myjsf2components.jar

       

      myWar1.war contains a Mojarra-1.2 (org.jboss.jbossfaces.JSF_CONFIG_NAME context-param in web.xml) webapp and myWar2.war a Mojarra-2.0 webapp (org.jboss.jbossfaces.JSF_CONFIG_NAME context-param in web.xml).

      All classes in wars are isolated using a jboss-classloading.xml file in WEB-INF folder

      My problem is that even if Mojarra-1.2 is specified in web.xml, jboss tries to deploy mywar1.war with Mojarra-2.03 (default jsf deployer).

      I can confirm that JSFImplManagementDeployer class picks up the right JSFImplMetaData implementation for mywar1.war but when jsf ConfigureListener class is initializing, the following trace in logs is displayed

       

      INFO  [javax.enterprise.resource.webcontainer.jsf.config] (Thread-2) Initialisation de Mojarra 2.0.3 ( b05) pour le contexte /mywar1.war

       

      Any idea of this switch between 1.2 and 2.0 implementation during war deployment ?

       

      Jérôme

        • 1. Running Two Mojarra config in single ear
          ssilvert

          Wow.  I dreamed about this but I never thought anyone would actually try it.  AS6 has only been out for two weeks and here we go!

           

          It's possible that what you have is actually working as expected.  The log message may be incorrect due to some variation of this issue: https://issues.jboss.org/browse/LOGMGR-17

           

          The more interesting part will concern which version of JSF is seen at the EAR level.  The JSFDeployer will add JSF to the classpath of your EAR if any WAR inside the EAR also uses JSF.  Since you have two different WARs with two different JSF versions, you will get both.  It is undefined which one will take precedence.

           

          Stan

          1 of 1 people found this helpful
          • 2. Re: Running Two Mojarra config in single ear
            jgautier

            Hi Stan, thanks for answering question.

            Well, I wouldn't have tried if not necessary I must migrate an "'old" project from jboss4 to jboss6.

            I would not say that JSF is seen at EAR level, it probably has to deal with EAR classes isolation (EARClassLoaderDeployer) since two Mojarra configurations can be ran if using two EAR.

            Moreover, the right JSF deployer is taken into account if in mywar1.war if defined in a completly isolated classloader (parent-domain!=DefaultDomain) but if i do that I'm not able to see anymore ear lib.

            Indeed, I would have expected to be able to run two Mojarra Configurations by providing org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL=true in web.xml but it doesn't seem to work with classloading isolation in wars.

            Anyway, say a little pray for me, I'll try to make Seam 2.2 application run on Mojarra 2.0.

             

            Jérôme

            • 3. Re: Running Two Mojarra config in single ear
              ssilvert

              If you have Seam at the EAR level then Seam may require JSF classes to be available to the EAR classloader. 

               

              Let me know how it goes.  I'll be interested in your results.

               

              Stan

              • 4. Re: Running Two Mojarra config in single ear
                jgautier

                Hi Stan,

                 

                If you're interested in my integration results, here we go:

                 

                • Seam 2.2 can work with a Mojarra 2.0 deployer if using the following deployment structure:

                 

                 

                myear.ear

                     |-->jboss-seam-2.2.1.CR3.jar (ejb)

                     |-->my-seam-controllers.jar (ejb)

                     |-->lib

                              |-->jsf-facelets-1.1.15.jar

                              |-->richfaces-api-3.3.3.Final.jar

                              |-->richfaces-impl-jsf2-3.3.3.Final.jar

                              |-->richfaces-ui-3.3.3.Final.jar

                              |--> jboss-seam-ui-2.2.1.CR3.jar

                     |-->my-seam-app.war (web module)

                              |-->WEB-INF/faces-config.xml (version=1.2, view-handler=com.sun.facelets.FaceletViewHandler)

                              |-->WEB-INF/web.xml (org.jboss.jbossfaces.JSF_CONFIG_NAME=Mojarra-2.0)

                 

                 

                 

                • However, the following deployment structure does not work anymore:

                 

                myear.ear

                     |-->jboss-seam-2.2.1.CR3.jar (ejb)

                     |-->my-seam-controllers.jar (ejb)

                     |-->lib

                              |-->richfaces-*-4.jar

                              |--> jboss-seam-ui-2.2.1.CR3.jar

                     |-->my-seam-app.war (web module)

                              |-->WEB-INF/faces-config.xml (version=2.0, removed view-handler)

                              |-->WEB-INF/web.xml (org.jboss.jbossfaces.JSF_CONFIG_NAME=Mojarra-2.0)

                     |-->my-jsf2-app.war

                               |-->WEB-INF/faces-config.xml (version=2.0, removed view-handler)         

                 

                my-seam-app.war still deploy without any error but my-jsf2-app.war deployment fails with the following exception:

                 

                2011-01-17 16:06:42,563 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (Thread-2) Unsanitized stacktrace from failed start...: java.lang.UnsupportedOperationException

                    at javax.faces.application.Application.getResourceHandler(Application.java:282) [:2.0.3-]

                    at org.jboss.weld.integration.webtier.jsf.ForwardingApplication.getResourceHandler(ForwardingApplication.java:293) [:6.0.0.Final]

                    at com.sun.faces.config.processor.ApplicationConfigProcessor.setResourceHandler(ApplicationConfigProcessor.java:748) [:2.0.3-]

                    at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:306) [:2.0.3-]

                    at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:110) [:2.0.3-]

                    at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:112) [:2.0.3-]

                    at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:110) [:2.0.3-]

                    at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:212) [:2.0.3-]

                    at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:332) [:2.0.3-]

                    at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:220) [:2.0.3-]

                    at org.jboss.web.jsf.integration.config.JBossMojarraConfigureListener.contextInitialized(JBossMojarraConfigureListener.java:58) [:1.0.3]

                 

                 

                • Finally, I've made a last attempt with a simple ear: a simple JSF 2 webapp in an ear, and a jboss-seam.jar or jboss-seam-ui.jar in classpath (ear lib or other)

                This trivial test confirmed me what I was suspecting: dice that a jboss-seam is found in deployment classpath, JSF 2 deployment fails with an UnsupportedOperationException. Removing jboss-seam jars from ear lib solves this UnsupportedOperation issue.

                 

                I think I'll have to wait for Seam 3 or migrate my "old" webapp to full JSF 2 since seam 2.2 is not fully compatible with Mojarra 2.0.

                 

                Jérôme

                • 5. Running Two Mojarra config in single ear
                  azakovorotny

                  Hi Jérôme,

                   

                  Have you tried a patched version of Seam 2.2 (https://github.com/heyoulin/seam2jsf2#readme)?

                  I was able to build JSF2/Richfaces4/Seam2.2 (patched) with maven and deploy it manually into Tomcat 6 only.

                  My attempts to deploy JSF2 simple app (no Seam) into JBoss 5.0.1 failed (yes, I've read and followed recommendations by Stan).

                  No matter what I do - I always get this:

                  java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory

                            at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:800)

                  • 6. Running Two Mojarra config in single ear
                    jgautier

                    Hi Andrew,

                     

                    I did my tests with seam 2.2.1 CR3, not with the patched version you mentionned in your post I'll have a look later.

                    Moreover, I don't know how jboss 5 handles JSF but I'm not sure that Mojarra 2.0 is supported controrary to jboss 6 which handles both Mojarra 1.2 and Mojarra 2.0 using configuration patterns in web.xml (specific jsf.deployers)

                    Regarding your problem, I think you'll probably have to upgrade Jboss 6 because:

                     

                    1. Seam 2.2 is not fully incompatible with Mojarra 2 (Seam221CR3AndJSF2)

                    2. Mojarra 2.0-Jboss 5 integration looks quite difficult(Jboss5-JSF2).

                     

                    Hope this helps,

                     

                    Jérôme

                    • 7. Re: Running Two Mojarra config in single ear
                      chriskulinski

                      Jerome,

                       

                      We've encountered a similar issue, also while attempting to upgrade an existing JBoss 4 app to JBoss 6 and start using JSF2.  In our previous app, we had one large EAR with Seam 2.2.1 and two included WARs - one with JSF1.2 and the other without JSF.  The JSF1.2 libraries were loaded at the EAR level.  As we attempted to add in JSF2, we encountered the issues you mentioned with Seam.  Seam 2.2.1 isn't compatible with JSF2.

                       

                      Our solution was to push Seam and JSF1.2 down into a single included WAR.  We were able to successfully run Seam/JSF1.2 isolated in that WAR.  We then created another WAR for JSF2, but had to load the JSF2 libs at the EAR level because of issues with the Weld deployer.  The deployer can only deploy Weld/CDI at the EAR level, so we needed the JSF2 libs to be loaded in the EAR.  We didn't need to specify any specifc classloader isolation configurations.  With this configuration, we have a running application with both Seam2.2.1/JSF1.2 and Weld/JSF2.

                       

                      Stan - thanks for your work creating the JSF deployer.  It would be helpful to others to update the (nicely written) documentation to highlight that the JSF deployer will deploy the specified JSF libraries at the EAR level.  That took us a while to track down.  Your earlier post validated that issue for us. 

                       

                      The log manager defect wasn't our issue.  If we specified two included WARs with different JSF versions in web.xml, we would see the JSF deployer pick one of the JSF configs at random and deploy that into the EAR both times. That's obviously not what we wanted it to do.  Instead we had to specifiy that one WAR (the Seam/JSF1.2 one) should use WAR_BUNDLES_JSF_IMPL=true and then include our own JSF1.2 libraries to be loaded at the WAR level.

                       

                      Thanks to both of you for your help in leading us to a working resolution.

                       

                      Chris