Uploaded image for project: 'XWork'
  1. XWork
  2. XW-621

buildResult does not handle additional parameters correctly

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 2.0.4
    • 2.1.2
    • Configuration
    • None
    • struts 2.0.11.1

    Description

      Using Struts2 2.0.11.1, I have a class annotated with the following struts result:

      @Result(name=Action.ERROR, type=ServletActionRedirectResult.class,

      value="settings", params={

      "namespace", "/tab",

      "error", "${errorMsg}"})

      This configuration value and parameters are then internally is treated as a HashMap,

      "error" -> "${errorMsg}",

      "actionName" -> "settings",

      "namespace" -> "/tab"

      However, this code in ObjectFactory.buildResult causes issues:

      try

      { OgnlUtil.setProperties(resultConfig.getParams(), result, extraContext, true); }

      catch (XWorkException ex) {

      Throwable reason = ex.getCause();

      if (reason instanceof OgnlException)

      { // ognl exceptions could be thrown and be ok if, for example, the result uses parameters in ways other than // as properties for the result object. For example, the redirect result from Struts 2 allows any parameters // to be set on the result, which it appends to the redirecting url. These parameters wouldn't have a // corresponding setter on the result object, so an OGNL exception could be thrown. Still, this is a misuse // of exceptions, so we should look at improving it. LOG.debug(ex.getMessage(), reason); }

      else

      { throw ex; }

      }

      As error is not defined on the result, it will throw an exception, but more importantly it will stop processing parameters. It looks like things such as ServletRedirectResult work with extra parameters just on the basis of those parameters being sequentially last on the iteration - something which works for LinkedHashMap, but not a plain HashMap .

      The solution (to my untrained eyes) would appear to be to pass false into setProperties as the last parameter, thus ignoring all exceptions and causing Ognl to log them as warnings. Otherwise, it would appear to be to set up the Ognl context as a compound root and have a discardable map sitting underneath to 'catch' all the unknown properties, thus only causing genuine errors to bubble up.

      Attachments

        Activity

          People

            mrdon Donald J. Brown
            dwaite David Waite
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: