javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-2021

ConfigManager swallows vital information from ConfigurationException

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: current
    • Fix Version/s: 2.1.2, 2.2.0-m01
    • Component/s: configuration
    • Labels:
      None
    • Status Whiteboard:
      Hide

      size_small importance_small jsf_2_1_2

      Show
      size_small importance_small jsf_2_1_2

      Description

      In case e.g. a custom NavigationHandler gets the wrong type of delegate passed in, we get a ConfigurationException like this:

      com.sun.faces.config.ConfigurationException:
      Source Document: jndi:/localhost/csJsfSample/WEB-INF/faces-config.xml
      Cause: Unable to create a new instance of 'com.csg.jsfcatalog.nav.GuidesNavigationHandler': java.lang.IllegalArgumentException: argument type mismatch

      Of course now it's clear that this NavigationHandler must implement ConfigurableNavigationHandler in JSF 2.0.

      The problem is, that in ConfigManager.initialize() line 378-379 the caught ConfigurationException is unwinded and repackaged into a new ConfigurationExcception but without the vital information from the original ConfigurationException:

      378 Throwable t = unwind(e);
      379 throw new ConfigurationException("CONFIGURATION FAILED! " + t.getMessage(), t);

      Probably it would be better to only wrap non-ConfigurationException and rethrow the caught ConfigurationException or new created ConfigurationException wrapping the complete caught exception.
      e.g. (see also attached patch file)

      } catch (Exception e) {
      // clear out any configured factories
      releaseFactories();
      Throwable t = e;
      if (!(e instanceof ConfigurationException))

      { t = new ConfigurationException("CONFIGURATION FAILED! " + t.getMessage(), t); }

      throw (ConfigurationException)t;
      } finally {

      There is a log statement to log the originial exception (line 373-377) - however, almost nobody ever activates INFO level for the JSF CONFIG logger ... and in case of an exception it's bad to not log the original exception. At least the log with level error should have a hint to activate INFO level on CONFIG logger to get the real cause ... or change this handling as hinted above.

      1. ConfigManager.patch
        1 kB
        Hanspeter Duennenberger

        Activity

        Hide
        rogerk added a comment -

        Committed to trunk
        Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigManager.java
        Transmitting file data .
        Committed revision 9037.

        Need to commit to MOJARRA_2_1X_ROLLING branch for 2.1.2 release.

        Show
        rogerk added a comment - Committed to trunk Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigManager.java Transmitting file data . Committed revision 9037. Need to commit to MOJARRA_2_1X_ROLLING branch for 2.1.2 release.
        Hide
        rogerk added a comment -

        Committed to 2_1_X branch:

        Sending ConfigManager.java
        Transmitting file data .
        Committed revision 9038.

        Show
        rogerk added a comment - Committed to 2_1_X branch: Sending ConfigManager.java Transmitting file data . Committed revision 9038.
        Hide
        rogerk added a comment -

        reopen to edit fix version

        Show
        rogerk added a comment - reopen to edit fix version
        Hide
        rogerk added a comment -

        fix version

        Show
        rogerk added a comment - fix version
        Hide
        rogerk added a comment -

        re-closing

        Show
        rogerk added a comment - re-closing

          People

          • Assignee:
            rogerk
            Reporter:
            Hanspeter Duennenberger
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: