On 9/29/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi Craig! Ok, lets concentrate only on the patch. Please, forget the discussion about speedup, this has nothing to do with the patch. I do not want to overload CONFIG_FILES nor change its meaning. Say you have a web.xml with the following configuration: javax.faces.CONFIG_FILES=/content/app/conf/faces-config.xml ,/content/app2/conf/faces-config.xml
OK, so lets continue the "twenty questions" game for a minute, and ask, why would you have a faces-config.xml file nested like this? JSF is going to ignore it as well. The whole point of the META-INF convention in the spec is so that you do not have to explicitly configure things like this. Second thing to note is that the spec defines this context init parameter as defining *context-relative* resource paths to faces-config.xml resources, not to classpath resources inside a JAR. Any application that relies on the latter (which I assume the MyFaces impl must be supporting?) is not going to be portable. Craig The first faces-config.xml is located in myapp.jar and the second one is
located in myapp2.jar. Both jars do NOT have a META-INF/faces-config.xml due to the use of javax.faces.CONFIG_FILES shale-tiger ignores those jars due to this fact. The patch do nothing else than to lookup those jars and add them to the list of webArchives. Just for safety I changed the List to a TreeSet. It is possible that such a jar contains a META-INF/faces-config.xml and also some additional special config.xml pointing to with javax.faces.CONFIG_FILES. To not parse them twice is the reason why I changed it to a Set. You see, no special tricks with javax.faces.CONFIG_FILES, nor any other style of class scanning. Ciao, Mario
