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

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

    Details

    • Type: Bug
    • Status: Closed
    • Priority: 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 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 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
        gjz22 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
        gjz22 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
        rainerh 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
        rainerh 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
        eugene Schava Eugene added a comment -

        Rainer and Gabriel

        You are understanding problems of ordinary developer. Carry on!

        Show
        eugene Schava Eugene added a comment - Rainer and Gabriel You are understanding problems of ordinary developer. Carry on!
        Hide
        rgielen 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
        rgielen 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
        rgielen Rene Gielen added a comment -

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

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

        My updates to fix this issue

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

        Thanks for the patch, added to CVS HEAD

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

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development