Regex-based exception encountered with dynaview in PrettyFaces 3/4

Splash Forums PrettyFaces Users Regex-based exception encountered with dynaview in PrettyFaces 3/4

This topic contains 6 replies, has 3 voices, and was last updated by  Lincoln Baxter III 10 years, 3 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #18038


    Hi guys,

    I’m not sure why I’m the only one who’s encountered this, but what I’m seeing is that my viewId is causing problems when PrettyFaces code attempts to treat it as a regex pattern. This happens in PrettyFilter in v3x, and in UrlMappingRuleAdaptor in v4, where the offending code is:

    if (url.decode().toURL().matches(viewId))

    url.decode().toURL() returns a String, so of course viewId is taken as a regex. This seems like an obvious case of “equals(), not matches() should be called.” When I rebuild v4 calling equals() the tests still pass (seemingly I have to ‘mvn -DskipTests clean install’; *then* ‘mvn clean install’ to have the tests behave in a normal fashion, presumably because of something to do with deploying the installed prettyfaces jars w/ Arquillian). This whole call is nested in an alternative block to ‘if (context.shouldProcessDynaview())’, however, which I take to mean that my use-case is somehow reaching this point with a dynaview viewId that apparently should *not* be processed, presumably already having *been* processed. I don’t have an extracted test-case yet; I rather wanted to run the high-level scenario past you guys in case you agreed to the changed method call right off, saving me some time. Surely it’s never the case that any viewid should be a regex pattern?




    Hey Matt,

    that’s indeed a very strange issue. I also don’t understand why the code is using matches() at this place. equals() would make more sense in my opinion. I don’t see any reason why the viewId should be a regular expression at this point.

    I think you can change this method call. This should be safe. However I would really like to hear Lincoln’s opinion on this. But he is currently at JavaOne, so it may take some time till be get his thoughts of this.



    agreed. I think this is a simple bug. write a test, fix it, and call it a day :)



    Writing a test would seem to be the tricky part, since the basic dynaview tests don’t seem to trigger it. :|


    Hey all,

    I just had a deeper look at this issue. In fact it has nothing to do with dynaview. The reason it also appears for dynaviews is that every dynaview request runs a second time through the filter (with shouldProcessDynaview() returning false).

    I was able to reproduce this issue with a simple mapping like this:

    <url-mapping id="test">
    <pattern value="/page" />
    <view-id value="/unusual-view-id-(.xhtml" />

    I added this as an Arquillian test to our test suite.

    As you see the view-id is not a valid regular expression, but a valid view-id. The old code in PrettyFilter and UrlMappingRuleAdaptor failed for this mapping. But after changing matches() to equals() everything works fine.

    I just pushed the fix upstream. So this shouldn’t be an issue any more.



    Great thinking for the example! Thanks, Christian!


    Awesome :) thanks christian!

Viewing 7 posts - 1 through 7 (of 7 total)

The forum ‘PrettyFaces Users’ is closed to new topics and replies.

Comments are closed.