Details
Major Description
I think a subtle logic bug crept into NavigationHandlerImpl handling on wildcard matches during this revision:
Here is the scenario:
there are two navigation rules:
<navigation-rule>
<from-view-id>/foo.jsp</from-view-id>
<navigation-case>
<from-outcome>success</from-outcome>
<to-view-id>/bar.jsp</to-view-id>
</navigation-case>
</navigation-rule>
<navigation-rule>
<navigation-case>
<from-outcome>foobar</from-outcome>
<to-view-id>/foobar.jsp</to-view-id>
</navigation-case>
</navigation-rule>
Assuming you are in the view /foo.jsp and your action method returns "foobar" you would expect to end up matching on the wildcard navigation rule and be sent to /foobar.jsp.
It looks like the logic on lines 71-72 and 75-79 are erroneous and should be removed as they are present in the getNavigationCase(...) method called on line 73. The net effect of the problem is that even if you find a good match from line 73, if your viewId returns a list from the casesMap the code ends up overwriting the previously determined navigation case with a null - this send you right back to rerendering the view as if you nav case wasn't there at all.
I took out the lines in question and tested locally and everything seems to work for me...
-Erik
Diff:
Index: core/impl/src/main/java/org/apache/myfaces/application/NavigationHandlerImpl.java
===================================================================
— core/impl/src/main/java/org/apache/myfaces/application/NavigationHandlerImpl.java (revision 415098)
+++ core/impl/src/main/java/org/apache/myfaces/application/NavigationHandlerImpl.java (working copy)
@@ -68,18 +68,8 @@
return;
}
- String viewId = facesContext.getViewRoot().getViewId();
- Map casesMap = getNavigationCases(facesContext);
NavigationCase navigationCase = getNavigationCase(facesContext, fromAction, outcome);
- List casesList = (List)casesMap.get(viewId);
- if (casesList != null)
- {
- // Exact match?
- navigationCase = calcMatchingNavigationCase(casesList, fromAction, outcome);
- }
-
-