Hi Craig, or should I say - good morning :-)
>> 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. Why will JSF ignore it? I dont understand what you mean. (I checked the JSR-RI source, please read on) Our application works using such a configuration like a charme. We use the myfaces JSF impl, but as far as I remember, this worked with JSF-RI too. > The whole point of the META-INF convention in the spec > is so that you do not have to explicitly configure things like this. Yes, I know this, but we decided to use the javax.faces.CONFIG_FILES way. > 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. I cant find a pointer to what you say about the spec, however, the way how your explicitResource() method works is the same as the one how myfaces lookup the faces-config.xml. The patch didn't change the way how to lookup resources pointed to by javax.faces.CONFIG_FILES. > Any application that relies on the > latter (which I assume the MyFaces impl must be supporting?) is not > going to > be portable. I had a look at the JSF-RI impl, there you will find in ConfigureListener the method "getContextURLForPath" which will be used to lookup the configuration files configured in javax.faces.CONFIG_FILES. This method use ServletContext.getResource(path) - the same as shale-tiger use, and for sure myfaces-impl. The two most important JSF implementations behaves the same way, also shale-tiger uses this strategy to lookup javax.faces.CONFIG_FILES configured faces-config.xml files. So my patch simply completes the webArchives lookup strategy. Ciao, Mario
