Uploaded image for project: 'PUBLIC - Liferay Faces'
  1. PUBLIC - Liferay Faces
  2. FACES-1603

IllegalStateException during portlet deployment on WebLogic: Could not find backup for factory javax.faces.context.FacesContextFactory

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: liferay-faces-3.1.2-ga3
    • Fix Version/s: liferay-faces-3.1.3-ga4
    • Component/s: ZZZ: Legacy - Test
    • Labels:
      None
    • Environment:
      WebLogic 10.3.6.0 + Liferay Portal 6.1.20 EE GA2 + liferay-fix-pack-plugin-deployment-1-6120
      WebLogic 10.3.6.0 + Liferay Portal 6.2.x

      Description

      For security purposes related to LPS-26321 (PACL), the fix for LPS-29103 made it so that WEB-INF/web.xml <listener> elements like the following:

      <listener>
          <listener-class&gt;com.sun.faces.config.ConfigureListener</listener-class&gt;
      </listener>
      <listener>
          <listener-class&gt;com.liferay.faces.bridge.servlet.BridgeSessionListener</listener-class&gt;
      </listener>
      

      ... will get consolidated into a context-param like the following:

      <context-param>
          <param-name>portalListenerClasses</param-name>
          <param-value>com.liferay.portal.kernel.servlet.SerializableSessionAttributeListener,com.sun.faces.config.ConfigureListener,com.liferay.faces.bridge.servlet.BridgeSessionListener</param-value>
      </context-param>
      

      This change was causing issues in certain environments, and LPS-37483 was opened in order to prevent this from happening when security-manager-enabled=false in WEB-INF/liferay-plugin-package.properties

      After several proposed fixes and much discussion, LPS-37483 was closed as "WONTFIX" because the portalListenerClasses context-param way of doing things solves a larger problem: since there is no guarantee about which WAR is loaded first by the servlet container, it is important to have portal's listeners fire before any portlet WAR listeners.

      Regardless, the portalListenerClasses context-param way of doing things can cause a problem on WebLogic. As the title of this issue describes, an IllegalStateException can be thrown during portlet deployment on WebLogic with the following error message: Could not find backup for factory javax.faces.context.FacesContextFactory.

      Background:

      In the original version of the Deploying JSF Portlets on Oracle WebLogic wiki article, the instructions said that the Mojarra jsf-api.jar and jsf-impl.jar dependencies live in the global classpath (meaning copying the files manually to weblogic/lib). Since then, the instructions have been updated so that they say to use the new JSF Shared Library developed in FACES-1664.

      For zero-config purposes, the jsf-impl.jar dependency has a TLD file that declares the Mojarra ConfigureListener in a TLD <listener> element. This is nice because it provides a convenience for developers, so that the listener does not need to be present in WEB-INF/web.xml.

      With the advent of FACES-1666 we have been able to remove the Mojarra ConfigureListener from the WEB-INF/web.xml descriptor of all the demo portlets, and we are no longer experiencing this issue.

      How to Reproduce (METHOD 1):

      1. Ensure that jsf-api.jar and jsf-impl.jar are present in the weblogic/lib global classpath.
      2. Ensure that jsf-api.jar and jsf-impl.jar are NOT present in the portlet WAR's WEB-INF/lib folder.
      3. Ensure that the Mojarra ConfigureListener is NOT present in the portlet WAR's WEB-INF/web.xml descriptor.

      Reason Why it Fails:

      • WebLogic is unable to activate the Mojarra ConfigureListener in the portlet webapp context because this is an incorrect way of having the Mojarra API and Implementation live in the global classpath.

      Workaround:

      • Mojarra should be deployed using the JSF Shared Library developed in FACES-1664
      • The following should be added to the WEB-INF/weblogic.xml descriptor:
        <wls:library-ref>
        	<wls:library-name>jsf</wls:library-name>
        </wls:library-ref>
        

      How to Reproduce (METHOD 2):

      1. Ensure that jsf-api.jar (but NOT jsf-impl.jar) is present in the weblogic/lib global classpath.
      2. Ensure that jsf-impl.jar (but NOT jsf-api.jar) is present in the portlet WAR's WEB-INF/lib folder.
      3. Ensure that the Mojarra ConfigureListener is present in the portlet WAR's WEB-INF/web.xml descriptor.

      Reason Why it Fails:

      • This is an incorrect way of having the Mojarra API live in the global classpath
      • Since the Mojarra ConfigureListener is INDEED present in WEB-INF/web.xml, the <listener> is removed by the Liferay hot deploy process and placed inside of the portalListenerClasses context-param. The Liferay SecurePluginContextListener (which is indeed registered as a <listener) then instantiates all of the FQCN's specified in the portalListenerClasses context-param, including the Mojarra ConfigureListener. Since WebLogic does not see ConfigureListener as a <listener> in WEB-INF/web.xml, it also attempts to register it via zero-config because of the TLD file in jsf-impl.jar.

      Workaround:

      • Remove the Mojarra ConfigureListener from the portlet WAR's WEB-INF/web.xml descriptor
      • Remove jsf-impl.jar from the portlet WAR's WEB-INF/lib folder
      • Mojarra should be deployed using the JSF Shared Library developed in FACES-1664
      • The following should be added to the WEB-INF/weblogic.xml descriptor:
        <wls:library-ref>
        	<wls:library-name>jsf</wls:library-name>
        </wls:library-ref>
        

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                neil.griffin Neil Griffin
                Reporter:
                neil.griffin Neil Griffin
                Participants of an Issue:
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Packages

                  Version Package
                  liferay-faces-3.1.3-ga4