I had wondered that myself for a time, as it would have made something I wrote easier. NavigationHandler really needs to change to make it more reusable (ability to get the settings from it instead of just that one method.
As for the information, it will not be so easy as there is not necessarily one faces configuration file. You can have multiple. You may for example, have some to setup renders for example in a JSF controls bean. Therefore the question is how to get the file that has your navigation code. The best thing I can think of is just to have a setting in your web.config with the location of the configuration file you wish to use.
Also be careful that if you are making a reusable component that you may want to stick to using the jsf resolution rules (supporting wildcards for example).
If your intent is to have access to all of the configured navigation rules, you'd be best served to parse *exactly* the same configuration files that the JSF runtime does ... that way, you don't care which of the potentially many configuration file(s) has those definitions. The JSF spec covers the details of what's required in Section 10.3.2, but it boils down to processing (in order):
* Any META-INF/faces-config.xml resources in the ServletContext resource paths
for this application (typically packaged inside a JAR file in /WEB-INF/lib).
* Any configuration resources configured on the context init parameter
"javax.faces.CONFIG_FILES".
* A resource named "/WEB-INF/faces-config.xml" (if it exists, and if it
has not already been parsed).
On the other hand, I would also be thinking hard about my motivations for wanting to do this kind of thing ... it seems like taking a very simple concept (outcome-driven navigation) and trying to make it something complicated. Customizing this will also make it harder for tools to give your users high quality support, because they are not going to understand what extra "stuff" you are providing.
Craig
