XWork
  1. XWork
  2. XW-360

Setting allowed and blocked parameters for ParameterFilterInterceptor is not working as expected

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.1
    • Fix Version/s: 1.1.2
    • Component/s: Interceptors
    • Labels:
      None
    • Flags:
      Important

      Description

      Parameters allowed and blocked have two setters - with string and collection and one getter returns collection
      In this cause default setter for this properties is setter accepted collection.
      And when I try to parametrize this interceptor using <param name="blocked">p1, p2</param> setter for collections is invoked with collection of one string "p1, p2".

      My proposition: rename (or remove!) setters and getters for parameters allowed and blocked working with collections.

      And change function asCollection(String) to calling TextParseUtil.commaDelimitedStringToSet

        Activity

        Hide
        tm_jee added a comment -

        Hi Eugene,

        I am thinking about this, if we manage to solve XW-340, in this case,

        <param name="blocked">$

        {'p1,p2'}

        </param>

        will result in the getter/setter with string argmunet being called, while

        <param name="blocked">$'p1','p2'</param>

        will result in the getter/setter with collection argument being called,

        Would this meet your expectation, such that this issue could be considered resolved? Let us know what you think. thx

        Show
        tm_jee added a comment - Hi Eugene, I am thinking about this, if we manage to solve XW-340 , in this case, <param name="blocked">$ {'p1,p2'} </param> will result in the getter/setter with string argmunet being called, while <param name="blocked">$ 'p1','p2' </param> will result in the getter/setter with collection argument being called, Would this meet your expectation, such that this issue could be considered resolved? Let us know what you think. thx
        Hide
        Gabriel Zimmerman added a comment -

        Since I put this in there I should comment

        My hope was that:

        <param name="blocked">p1,p2</param>

        It is less verbose than:
        <param name="blocked">$'p1','p2'</param>
        and less probe to error.

        would call the string method which would then populate the collection.

        How do people want to see this, and is there a convention of how this is done in other Interceptors?

        Show
        Gabriel Zimmerman added a comment - Since I put this in there I should comment My hope was that: <param name="blocked">p1,p2</param> It is less verbose than: <param name="blocked">$ 'p1','p2' </param> and less probe to error. would call the string method which would then populate the collection. How do people want to see this, and is there a convention of how this is done in other Interceptors?
        Hide
        Rainer Hermanns added a comment -

        Gabe,
        yes, this (<param name="blocked">p1,p2</param> ) would be the way I would expect it to work but perhaps we can add OGNL expression evaluation as well. This could be usefull in other cases as stated in XW-340.

        What do you think?

        Show
        Rainer Hermanns added a comment - Gabe, yes, this (<param name="blocked">p1,p2</param> ) would be the way I would expect it to work but perhaps we can add OGNL expression evaluation as well. This could be usefull in other cases as stated in XW-340 . What do you think?
        Hide
        Schava Eugene added a comment -

        Rainer and Gabriel

        You are understanding problems of ordinary developer. Carry on!

        Show
        Schava Eugene added a comment - Rainer and Gabriel You are understanding problems of ordinary developer. Carry on!
        Hide
        Rene Gielen added a comment -

        This issue was not scheduled yet. Was this by intention? Was it planned to make it into 1.1.2?

        Show
        Rene Gielen added a comment - This issue was not scheduled yet. Was this by intention? Was it planned to make it into 1.1.2?
        Hide
        Rene Gielen added a comment -

        Any volunteers for this one? Could make it into 1.1.2 if resolved until 2006-03-22

        Show
        Rene Gielen added a comment - Any volunteers for this one? Could make it into 1.1.2 if resolved until 2006-03-22
        Hide
        Schava Eugene added a comment -

        My updates to fix this issue

        Show
        Schava Eugene added a comment - My updates to fix this issue
        Hide
        Rainer Hermanns added a comment -

        Thanks for the patch, added to CVS HEAD

        Show
        Rainer Hermanns added a comment - Thanks for the patch, added to CVS HEAD

          People

          • Assignee:
            Rainer Hermanns
            Reporter:
            Schava Eugene
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development