MyFaces Core
  1. MyFaces Core
  2. MYFACES-1338

MyFaces is initialized twice in Portlet

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1.4-SNAPSHOT
    • Fix Version/s: None
    • Component/s: Portlet_Support
    • Labels:
      None
    • Environment:
      Windows XP / Tomcat 5.5.17 / Liferay 4.0.0.

      Description

      I'm using MyFaces 1.1.4 within a portlet and I'm noticing that MyFaces is being initialized twice. Its causing a warning because multiple copies of my managed beans are being created. Here is the log output, I'm using Liferay 4.0.0 and tomcat 5.5.17.

      20:52:52,517 INFO [com.liferay.portal.deploy.AutoDeployPortletListener] Portlets for \home\liferay\deploy\MyMessagesPortlet.war copied successfully
      20:53:00,122 INFO [org.apache.catalina.startup.HostConfig] Reloading context [/MyMessagesPortlet]
      DEBUG [org.apache.myfaces.webapp.StartupServletContextListener.initFaces(60)] Initializing MyFaces
      INFO [org.apache.myfaces.config.FacesConfigurator.feedStandardConfig(151)] Reading standard config org/apache/myfaces/resource/standard-faces-config.xml
      INFO [org.apache.myfaces.config.FacesConfigurator.feedClassloaderConfigurations(250)] Reading config jar:file:/D:/liferay4/webapps/MyMessagesPortlet/WEB-INF/lib/jsf-facelets.jar!/META-INF/faces-config.xml
      INFO [org.apache.myfaces.config.FacesConfigurator.feedClassloaderConfigurations(250)] Reading config jar:file:/D:/liferay4/webapps/MyMessagesPortlet/WEB-INF/lib/tomahawk-1.1.2-SNAPSHOT.jar!/META-INF/faces-config.xml
      INFO [org.apache.myfaces.config.FacesConfigurator.feedWebAppConfig(411)] Reading config /WEB-INF/faces-config.xml
      INFO [org.apache.myfaces.renderkit.html.HtmlRenderKitImpl.addRenderer(104)] Overwriting renderer with family = javax.faces.Command rendererType = javax.faces.Button renderer class = org.apache.myfaces.renderkit.html.jsf.DummyFormHtmlButtonRenderer
      INFO [org.apache.myfaces.renderkit.html.HtmlRenderKitImpl.addRenderer(104)] Overwriting renderer with family = javax.faces.Command rendererType = javax.faces.Link renderer class = org.apache.myfaces.renderkit.html.jsf.DummyFormHtmlLinkRenderer
      INFO [org.apache.myfaces.webapp.StartupServletContextListener.initFaces(96)] ServletContext 'D:\liferay4\webapps\MyMessagesPortlet\' initialized.
      20:53:02,575 INFO [com.liferay.portal.deploy.HotDeployPortletListener] Registering portlets for MyMessagesPortlet
      20:53:02,606 INFO [com.liferay.portal.deploy.HotDeployPortletListener] Portlets for MyMessagesPortlet registered successfully
      Loading jar:file:/D:/liferay4/liferay/WEB-INF/lib/portal-ejb.jar!/portal.properties for liferay.com
      Loading file:/D:/liferay4/liferay/WEB-INF/classes/portal-ext.properties for liferay.com
      Loading jar:file:/D:/liferay4/liferay/WEB-INF/lib/portal-ejb.jar!/cache-single-vm.properties
      DEBUG [com.teradata.portlet.MultiModePortlet.init(32)] View page = /view.xhtml
      DEBUG [com.teradata.portlet.MultiModePortlet.init(33)] Edit page = /edit.xhtml
      DEBUG [com.teradata.portlet.MultiModePortlet.init(34)] Help page = /help.xhtml
      DEBUG [org.apache.myfaces.portlet.MyFacesGenericPortlet.initMyFaces(178)] Initializing MyFaces
      INFO [org.apache.myfaces.config.FacesConfigurator.feedStandardConfig(151)] Reading standard config org/apache/myfaces/resource/standard-faces-config.xml
      INFO [org.apache.myfaces.config.FacesConfigurator.feedClassloaderConfigurations(250)] Reading config jar:file:/D:/liferay4/webapps/MyMessagesPortlet/WEB-INF/lib/jsf-facelets.jar!/META-INF/faces-config.xml
      INFO [org.apache.myfaces.config.FacesConfigurator.feedClassloaderConfigurations(250)] Reading config jar:file:/D:/liferay4/webapps/MyMessagesPortlet/WEB-INF/lib/tomahawk-1.1.2-SNAPSHOT.jar!/META-INF/faces-config.xml
      INFO [org.apache.myfaces.config.FacesConfigurator.feedWebAppConfig(411)] Reading config /WEB-INF/faces-config.xml
      INFO [org.apache.myfaces.renderkit.html.HtmlRenderKitImpl.addRenderer(104)] Overwriting renderer with family = javax.faces.Command rendererType = javax.faces.Button renderer class = org.apache.myfaces.renderkit.html.jsf.DummyFormHtmlButtonRenderer
      INFO [org.apache.myfaces.renderkit.html.HtmlRenderKitImpl.addRenderer(104)] Overwriting renderer with family = javax.faces.Command rendererType = javax.faces.Link renderer class = org.apache.myfaces.renderkit.html.jsf.DummyFormHtmlLinkRenderer
      INFO [org.apache.myfaces.renderkit.RenderKitFactoryImpl.addRenderKit(54)] RenderKit with renderKitId 'HTML_BASIC' was replaced.
      WARN [org.apache.myfaces.config.FacesConfigurator.configureRuntimeConfig(588)] More than one managed bean w/ the name of 'messages' - only keeping the last
      WARN [org.apache.myfaces.config.FacesConfigurator.configureRuntimeConfig(588)] More than one managed bean w/ the name of 'form' - only keeping the last

      Both org.apache.myfaces.webapp.StartupServletContextListener.initMyFaces() and org.apache.myfaces.portlet.MyFacesGenericPortlet.initMyFaces() check a context attribute to see if MyFaces is initialized before invoking org.apache.myfaces.config.FacesConfigurator.configure() but both actually check and set a different attribute name.

      StartupServletContextListener uses:

      static final String FACES_INIT_DONE
      = StartupServletContextListener.class.getName() + ".FACES_INIT_DONE";

      MyFacesGenericPortlet uses:

      protected static final String FACES_INIT_DONE =
      MyFacesGenericPortlet.class.getName() + ".FACES_INIT_DONE";

      I find that if I override MyFacesGenericPortlet.initMyFaces() to do nothing, everythings works and I avoid the duplicate managed bean warnings.

        Issue Links

          Activity

          Show
          Dave Brondsema added a comment - Mailing list thread: http://mail-archives.apache.org/mod_mbox/myfaces-users/200606.mbox/%3c4890762.post@talk.nabble.com%3e
          Show
          Mike Kienenberger added a comment - http://wiki.apache.org/myfaces/FAQ#issueOrEmail
          Hide
          Eric Scheie added a comment -

          Why was this marked invalid? I posted to the user forum first and Matthias asked me to open a JIRA issue.

          Show
          Eric Scheie added a comment - Why was this marked invalid? I posted to the user forum first and Matthias asked me to open a JIRA issue.
          Hide
          Eric Scheie added a comment -

          I did post on the user forum first and someone told me to open a JIRA issue. So just referencing http://wiki.apache.org/myfaces/FAQ#issueOrEmail doesn't explain why this issue was marked invalid.

          Show
          Eric Scheie added a comment - I did post on the user forum first and someone told me to open a JIRA issue. So just referencing http://wiki.apache.org/myfaces/FAQ#issueOrEmail doesn't explain why this issue was marked invalid.
          Hide
          Mike Kienenberger added a comment -

          My apologies, Eric. I shouldn't have closed this issue. I didn't read it closely enough. Sorry for the inconvenience.

          Show
          Mike Kienenberger added a comment - My apologies, Eric. I shouldn't have closed this issue. I didn't read it closely enough. Sorry for the inconvenience.
          Hide
          Michael Lipp added a comment -

          The problem is caused by putting the listener registration for MyFaces initialization in myfaces_core.tld (instead of doing it in web.xml). Thus initial initialization with the servlet context cannot be avoided. On the other hand side, the MyFaces servlet must be re-initialized with the portlet external context in the portlet bridge.

          My workaround is to remove the listener registration from the TLD. If the developers do not want to move the registration from TLD to web.xml, a possible solution would be to add a servlet context parameter that is to be set for portlet usage and only does things that are independant of the context (or northing at all) and provide a different initialization method to be called from the portlet bridge.

          Show
          Michael Lipp added a comment - The problem is caused by putting the listener registration for MyFaces initialization in myfaces_core.tld (instead of doing it in web.xml). Thus initial initialization with the servlet context cannot be avoided. On the other hand side, the MyFaces servlet must be re-initialized with the portlet external context in the portlet bridge. My workaround is to remove the listener registration from the TLD. If the developers do not want to move the registration from TLD to web.xml, a possible solution would be to add a servlet context parameter that is to be set for portlet usage and only does things that are independant of the context (or northing at all) and provide a different initialization method to be called from the portlet bridge.
          Hide
          Dave Brondsema added a comment -

          Here's a theoretical question: what happens if you want to have a JSF webapp containing both servlets and portlet(s)? Do you need two initializations for the two contexts?

          Show
          Dave Brondsema added a comment - Here's a theoretical question: what happens if you want to have a JSF webapp containing both servlets and portlet(s)? Do you need two initializations for the two contexts?
          Hide
          Michael Lipp added a comment -

          No problem with that. There is a common misunderstanding about the nature of portlets: portlets are servlets. The portlet.xml is (by specification) to be read as an extension of the web.xml (because the JSR-168 group couldn't write the extensions in the web.xml).

          So we are talking about servlets in any case here.

          The difference between the two situations is that all information required to initialize MyFaces in a stand-alone context is available when the servlet is loaded. In a portlet context, the required information becomes only available when the portlet is first called.

          If you want to be independant of the usage scenario, the MyFaces implementation should simply postpone all ExternalContext related initialization work until lifecycle.execute or lifecycle.render is first called.

          Show
          Michael Lipp added a comment - No problem with that. There is a common misunderstanding about the nature of portlets: portlets are servlets. The portlet.xml is (by specification) to be read as an extension of the web.xml (because the JSR-168 group couldn't write the extensions in the web.xml). So we are talking about servlets in any case here. The difference between the two situations is that all information required to initialize MyFaces in a stand-alone context is available when the servlet is loaded. In a portlet context, the required information becomes only available when the portlet is first called. If you want to be independant of the usage scenario, the MyFaces implementation should simply postpone all ExternalContext related initialization work until lifecycle.execute or lifecycle.render is first called.

            People

            • Assignee:
              Martin Marinschek
              Reporter:
              Eric Scheie
            • Votes:
              5 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:

                Development