[MYFACES-2998] FacesConfig ordering must not be an SPI task

• Type: Task
• Status: Closed
• Priority: Major
• Resolution: Duplicate
• Affects Version/s: 2.0.2
• Component/s: SPI
• Assignee: Jakob Korherr
• Reporter: Jakob Korherr
• Created: 08/Dec/10 12:52
• Updated: 08/Dec/10 20:22
• Resolved: 08/Dec/10 20:05

Description

Currently the FacesConfigurationProvider provides the following methods to get the FacesConfig data from different sources:

• getStandardFacesConfig()
• getMetaInfServicesFacesConfig()
• getAnnotationsFacesConfig()
• getClassloaderFacesConfig()
• getContextSpecifiedFacesConfig()
• getWebAppFacesConfig()

Unfortunately it also provides a method that should combine all these data: getFacesConfigData(). This method is here due to refactorings, but IMHO this is the last place where it should be put, because it gets "its own implementation" via its Factory and then calls all of the above methods on it. I know this was introduced to support wrapping the default impl, but it really is very, very ugly.

Because of the fact that the faces-config merging (and ordering) is a very complex task and there is only one "right" way to do it (per JSF 2.0 spec), this must not be done by a custom SPI implementation. This code should be provided by MyFaces only.

Thus IMO the right way to solve this problem is to move all merging and ordering code into its own, MyFaces-specific class. This class (and not the SPI) should provide the getFacesConfigData() method. This means that in FacesConfigurator.configure() we should first get the FacesConfigurationProvider SPI impl and then pass it to FacesConfigMerger.getFacesConfigData().

NOTE that with this approach custom FacesConfigurationProvider impls (like in Geronimo) do not have to deal with this complex merging and ordering stuff and their life is a lot easier!

Issue Links

• duplicates: MYFACES-2945 Make a way to get the FacesConfig from a provider