1
votes

Suppose the following:

In a jar file you have a META-INF/faces-config.xml file with the following navigation rule:

 <navigation-rule>
  <from-view-id>/path/page1.xhtml</from-view-id>
  <navigation-case>
    <from-outcome>success</from-outcome>
    <to-view-id>/path/result.xhtml</to-view-id>
  </navigation-case>
 </navigation-rule>

And I would like to override this navigation rule in my web application, so I put the following navigation rule in WEB-INF/faces-config.xml as follows:

 <navigation-rule>
  <from-view-id>/path/page1.xhtml</from-view-id>
  <navigation-case>
    <from-outcome>success</from-outcome>
    <to-view-id>/path/my_custom_result.xhtml</to-view-id>
  </navigation-case>
 </navigation-rule>

So when I am in the page /path/page1.xhtml and an action outcome is success I suppose that the navigation case in WEB-INF/faces-config.xml is the outcome (i.e. /path/my_custom_result.xhtml) but unfortunatly the outcome is the one in the jar META-INF/faces-config.xml (i.e. /path/result.xhtml). Although looking at the code those two cases are in a java.util.Set so the order is not even guaranteed!

the first question is do you think this is a bug? although in the JSF specification this situation is not mentioned, but I think its good sense to have the local faces-config.xml configurations override the ones in the jar files.

second question is: I know that I can create a custom NavigationHandler, but looking to the com.sun.faces.application.NavigationHandlerImpl I didn't understand how I could know from which faces-config.xml file a NavigationCase comes.

Any ideas or suggestions?

Thanks guys.


Regarding Eelke answer:

This is the ADF documentation, what I was looking is the JSF 2.0 specification that you can find here: http://download.oracle.com/otndocs/jcp/jsf-2.0-fr-eval-oth-JSpec/ and there I found the following line

It is an error to specify more than one <navigation-case>,nested
within one or more <navigation-rule> elements with the same
<from-view-id>matching pattern, that have exactly the same combination
of <from-xxx>, unless each is discriminated by a unique <if> element.

Which makes me think that what I am trying to do is not possible although some JSF implementations could have a slight different behavior for this situation (ADF for example).

Regarding the duplicates the NavigationCase.equals method checks that all the attributes are the same, and in my case the toViewID is different so they are not equal.

1
"Although looking at the code those two cases are in a java.util.Set so the order is not even guaranteed!" You're implying that a Set never guarantees the order. You're wrong. It's the Set implementation which controls that. The HashSet for example does indeed not guarantee the order. The TreeSet guarantees the order by sorting. The LinkedHashSet guarantees the order by insertion. The JSF implementation uses LinkedHashSet to collect navigation cases. The main difference between Set and List is that the Set guarantees uniqueness (i.e. no duplicate elements allowed).BalusC
Yes BalusC you are right about the implementations of the Set and I was wrong in phrasing that, The problem is that I don't have any guarntee on how those NavigationCase's are inserted on the Set even if the Set being used is one that maintans the order of insertion. The NavigationCase in the jar file should not be there at all.Omar Al Kababji

1 Answers

1
votes

This page clearly states in paragraph 9.2.4.3 second alinea:

If there is a conflict in which two or more cases have the same from-view-id, from-action, and from-outcome values, the last case (as they are listed in the faces-config.xml) is used. If the conflict is among rules defined in different configuration files, the rule in the last configuration file to be loaded is used. Configuration files are loaded in the order they appear in the web.xml file.

And this page clearly states at the bottom:

If an application uses several JSF configuration files, at runtime JSF finds and loads the application's configuration settings in the following order:

Searches for files named META-INF/faces-config.xml in any JAR files for the application, and loads each as a configuration resource (in reverse order of the order in which they are found).

Searches for the javax.faces.CONFIG_FILES context parameter set in the application's web.xml file. JSF then loads each named file as a configuration resource.

Searches for a file named faces-config.xml in the WEB-INF directory and loads it as a configuration resource.

So it would seem to be a bug or you have something not quite right which causes it not to load the rules in your WEB-INF/faces-config.xml. Do you have navigations cases in there that actually do work? You also might want to check your logs. Sometimes an application is succesfully deployed but there are some warnings about things being ignored or not quite right.

BTW a Set might not define an order but it does not allow duplicates so there should only be one match. Namely the last value inserted for the key.