On 9/29/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi Craig,
or should I say - good morning :-)
Yep, at the moment :-).
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.
See below.
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.
I think I was assuming from your description that the actual
faces-config.xml file was buried inside a JAR file inside WEB-INF/lib. If
that's not the case, then the discussion below about whats supported is not
relevant.
One thing to note, however, is that if your faces-config.xml resource *is* a
static resource under the content directory in your web application, then it
is accessible to web clients that do a GET on the appropriate URL. Some
people (including me :-) would consider this a security hole.
Second thing to note is that the spec defines this context init
> parameter as
> defining *context-relative* resource paths to faces-config.xmlresources,
> 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.
See Section 10.1.3, first bullet:
javax.faces.CONFIG_FILES -- Comma-delimited list of context relative
resource paths under which the JSF implementation will look for
application
configuration resources (see Section 10.4.3 "Application Configuration
Resource Format") before loading a configuration resource named
"/WEB-INF/faces-config.xml" (if such a resource exists).
The RI class that reads this init parameter (
com.sun.faces.config.ConfigureListener obeys this definition ... it treats
all the paths as context relative, not class loader relative.
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.
Right. That looks for a static resource in the webapp, not a resource
buried inside a JAR file,. because it uses ServletContext.getResource()
instead of ClassLoader.getResource().
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
Craig
