MyFaces Core
  1. MyFaces Core
  2. MYFACES-2134

org.apache.myfaces.CONFIG_REFRESH_PERIOD != 0 causes a myfaces failure

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.5
    • Fix Version/s: 1.2.7
    • Component/s: General
    • Labels:
      None
    • Environment:
      Linux, JDK 1.5, Tomcat 6

      Description

      When the context param org.apache.myfaces.CONFIG_REFRESH_PERIOD is != 0 (which seems to be the default) the second page request causes a
      javax.faces.FacesException: Undefined component type javax.faces.ViewRoot Exception.

      In FacesConfigurator.class method void update() the method purgeConfiguration() is called. This method throws an NoSuchMethodException. In the catch block for this Exception there is a return; - so the configure(); below isn't called.

      It looks like RenderKitFactory and / or CoreRenderKitFactory (trinidad) doesn't implement the purgeRenderKit method which is called by reflection from the purgeConfiguration() method - so the Exception rises up.

      Setting the context param org.apache.myfaces.CONFIG_REFRESH_PERIOD to 0 works because the purgeConfiguration() is never called then.

      Regards from Felix @itemis Bonn

        Activity

        Hide
        Leonardo Uribe added a comment -

        From my point of view (personal opinion), this is not a blocker issue, because this only happens with a specific configuration (myfaces 1.2.x + trinidad).

        There are several possible ways:

        1. Do nothing, since it is a myfaces specific feature.
        2. Create a method purgeRenderKit on trinidad renderkit.
        3. Log a message when NoSuchMethodException is thrown, and continue processing, but it is ignored if some side effect occur.

        Since this is a myfaces specific feature, and a valid workaround is present, I'll lower the priority to major.

        Show
        Leonardo Uribe added a comment - From my point of view (personal opinion), this is not a blocker issue, because this only happens with a specific configuration (myfaces 1.2.x + trinidad). There are several possible ways: 1. Do nothing, since it is a myfaces specific feature. 2. Create a method purgeRenderKit on trinidad renderkit. 3. Log a message when NoSuchMethodException is thrown, and continue processing, but it is ignored if some side effect occur. Since this is a myfaces specific feature, and a valid workaround is present, I'll lower the priority to major.
        Hide
        Felix Becker added a comment -

        What the hell?!

        @ 1. (Do nothing): Are you serious about that? It's a feature which seems to be enabled by default. Its implemented in a normal release. So "Do nothing" is definitly not the right way.

        @2. That would be a improvement in trinidad, but that doesn't solve the core problem in MyFaces.

        @3. A message is already logged. Continue processing is the right way i think.

        Felix

        Show
        Felix Becker added a comment - What the hell?! @ 1. (Do nothing): Are you serious about that? It's a feature which seems to be enabled by default. Its implemented in a normal release. So "Do nothing" is definitly not the right way. @2. That would be a improvement in trinidad, but that doesn't solve the core problem in MyFaces. @3. A message is already logged. Continue processing is the right way i think. Felix
        Hide
        Val Blant added a comment -

        Leonardo, this is not a "myfaces 1.2.x + trinidad" issue only. This is a myfaces 1.2.x + any other framework that provides a custom RenderKitFactory issue.

        "purgeRenderKit" method is not a part of the RenderKitFactory interface, so no framework will implement it, unless they are specifically trying to be compatible with MyFaces.

        For example, consider org.ajax4jsf.renderkit.ChameleonRenderKitFactory, which is the RenderKitFactory you end up with when using RichFaces. It doesn't have a purgeRenderKit method and thus results in exactly the same problem.

        Show
        Val Blant added a comment - Leonardo, this is not a "myfaces 1.2.x + trinidad" issue only. This is a myfaces 1.2.x + any other framework that provides a custom RenderKitFactory issue. "purgeRenderKit" method is not a part of the RenderKitFactory interface, so no framework will implement it, unless they are specifically trying to be compatible with MyFaces. For example, consider org.ajax4jsf.renderkit.ChameleonRenderKitFactory, which is the RenderKitFactory you end up with when using RichFaces. It doesn't have a purgeRenderKit method and thus results in exactly the same problem.
        Hide
        Val Blant added a comment -

        This patch fixes the problem.

        The fix gets a reference to all of the required purge methods and starts the purging only if all methods were available.

        This prevents the situation where the ApplicationImpl gets purged, but then FacesConfigurator.configure() is never called due to the NoSuchMethodException thrown when attempting to purge the RenderKits.

        Show
        Val Blant added a comment - This patch fixes the problem. The fix gets a reference to all of the required purge methods and starts the purging only if all methods were available. This prevents the situation where the ApplicationImpl gets purged, but then FacesConfigurator.configure() is never called due to the NoSuchMethodException thrown when attempting to purge the RenderKits.
        Hide
        Leonardo Uribe added a comment -

        Thanks to Val Blant for provide this patch

        Show
        Leonardo Uribe added a comment - Thanks to Val Blant for provide this patch
        Hide
        Bernd Bohmann added a comment -

        May be the same error exists in myfaces 2.0.0?.

        Show
        Bernd Bohmann added a comment - May be the same error exists in myfaces 2.0.0?.
        Hide
        Leonardo Uribe added a comment -

        Merged revision 698037 to 743106 from 1.2.x to 2.0 branch

        Show
        Leonardo Uribe added a comment - Merged revision 698037 to 743106 from 1.2.x to 2.0 branch

          People

          • Assignee:
            Leonardo Uribe
            Reporter:
            Felix Becker
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development