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:
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?
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.
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:
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.