LimitActionFactoryImpl attempts to decode parameters that have already been decoded

[GoogleCodeExporter]

Here is the code from LimitActionFactoryImpl:

        for (Object param : parameters.keySet()) {
            String parameter = (String) param;
            if (parameter.startsWith(prefixId + Action.FILTER.toParam())) {
                String value = LimitUtils.getValue(parameters.get(parameter));
                try {
                    value = decode(value, "UTF-8");
                } catch (UnsupportedEncodingException e) {
                    e.printStackTrace();
                }
                if (StringUtils.isNotBlank(value)) {
                    String property = StringUtils.substringAfter(parameter,
prefixId + Action.FILTER.toParam());
                    Filter filter = new Filter(property, value);
                    filterSet.addFilter(filter);
                }
            }
        }

I entered a value like this into the filter: %-26-% (for a "LIKE" query)

I got this exception:

[3/4/09 10:00:08:906 EST] 0000003a WebApp        E   [Servlet
Error]-[JMesaSupportServlet]: java.lang.IllegalArgumentException:
URLDecoder: Incomplete trailing escape (%) pattern
    at java.net.URLDecoder.decode(URLDecoder.java:180)
    at
org.jmesa.limit.LimitActionFactoryImpl.getFilterSet(LimitActionFactoryImpl.java:
92)
    at org.jmesa.limit.LimitFactoryImpl.createLimit(LimitFactoryImpl.java:120)
    at org.jmesa.facade.TableFacadeImpl.getLimit(TableFacadeImpl.java:182)

Is there a reason why LimitActionFactory is trying to decode the parameters
there, when they should have already been decoded by the app server?  If
so, can we just catch the IllegalArgumentException and drive on with the
raw value if this case occurs?

Or am I doing something wrong?

Thanks.

Original issue reported on code.google.com by bgo...@e1b.org on 4 Mar 2009 at 3:11

[GoogleCodeExporter]

That particular code may have originally come over from the eXtremeTable. If 
you take
that out does it still work fine? Your right that the parameters will be 
decoded by
the app server. If you able to test it out let me know what you find. I can do 
some
testing myself this week. I want to validate that things like the worksheet 
still
work fine.

Original comment by jeff.johnston.mn@gmail.com on 4 Mar 2009 at 8:03

[GoogleCodeExporter]

If you get the chance to test this out I could do another release within a 
couple weeks.

Original comment by jeff.johnston.mn@gmail.com on 9 Mar 2009 at 6:24

• Changed state: Accepted

[GoogleCodeExporter]

Reply, ok, I'll give it a shot.  Sorry I didn't reply the first time, been a 
little 
busy.

Original comment by bgo...@e1b.org on 9 Mar 2009 at 6:36

[GoogleCodeExporter]

I totally understand. I am investigating converting over our Oracle database to 
MySQL
so I am just updating JMesa as I have needs or get patches...

Original comment by jeff.johnston.mn@gmail.com on 10 Mar 2009 at 2:51

[GoogleCodeExporter]

Just tested this by commenting out the try/catch block show above, and it seems 
to
work fine.

Original comment by bgo...@e1b.org on 11 Mar 2009 at 6:31

[GoogleCodeExporter]

The change makes sense to me as well. I will take out those lines of code and 
update
trunk tonight. I will also be doing another release within a week.

Thanks for testing it out!

Original comment by jeff.johnston.mn@gmail.com on 11 Mar 2009 at 6:53

[GoogleCodeExporter]

The change is on the trunk now...it will be released in the next few days.

Original comment by jeff.johnston.mn@gmail.com on 12 Mar 2009 at 3:38

[GoogleCodeExporter]

Part of the 2.4.2 release.

Original comment by jeff.johnston.mn@gmail.com on 5 Apr 2009 at 1:19

• Changed state: Done