I didn't know MyFaces had added warnings like that.  What version of MyFaces are you using?  OR Is it something the Sun App server 8.2 is doing only on deploy or did you get that log entry every time you started your webapp?  Nifty.
 
Regards,
David Friedman / [EMAIL PROTECTED]
-----Original Message-----
From: Cosma Colanicchia [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 09, 2006 11:31 AM
To: MyFaces Discussion
Subject: Re: Deployment warning: /WEB-INF/faces-config.xml has been specified in the javax.faces.CONFIG_FILES context parameter of the deployment descriptor

AFAIK, WEB-INF/faces-config.xml is loaded by default, you have to list only additional faces-config files in your web.xml

Cosma


2006/5/9, Todd Patrick < [EMAIL PROTECTED]>:
When I deploy a Myfaces based project to Sun Java System Application Server 8.2, I receive the following warning:
 
[#|2006-05-09T10:13:14.005-0500|WARNING|sun-appserver-pe8.2|org.apache.myfaces.config.FacesConfigurator|_ThreadID=11;|/WEB-INF/faces-config.xml has been specified in the javax.faces.CONFIG_FILES context parameter of the deployment descriptor. This should be removed, as it will be loaded twice.  See JSF spec 1.1, 10.3.2|#]
 
Therefore, I went and looked at the JSF spec 1.1 as noted below. What should I be removing to clear this warning?
 
I checked my web.xml file and it does have:
 
<context-param>
<param-name>javax.faces.CONFIG_FILES</param-name>
<param-value>/WEB-INF/faces-config.xml</param-value>
</context-param>
 
Is it ok to remove this, since my faces-config.xml is in the /WEB-INF directory? I just want to double-check.
 
Thanks,
 
--Todd
 
 
JSF spec 1.1, 10.3.2:
 
At application startup time, before any requests are processed, the JSF implementation must process zero or more application configuration resources, located according to the following algorithm:
 
Search for all resources named "META-INF/faces-config.xml" in the ServletContext resource paths for this web application, and load each as a JSF configuration resource (in reverse order of the order in which they are returned by getResources()).
 
Check for the existence of a context initialization parameter named javax.faces.CONFIG_FILES. If it exists, treat it as a comma-delimited list of context relative resource paths (starting with a "/"), and load each of the specfied resources.
 
Check for the existence of a web application configuration resource named "/WEB-INF/faces-config.xml", and load it if the resource exists.
 
This algorithm provides considerable flexibility for developers that are assembling the components of a JSF-based web application. For example, an application might include one or more custom UIComponent implementations, along with associated Renderers, so it can declare them in an application resource named "/WEBINF/ faces-config.xml" with no need to programmatically register them with Application instance. In addition, the application might choose to include a component library (packaged as a JAR file) that includes a "META-INF/facesconfig. xml" resource. The existence of this resource causes components, renderers, and other JSF implementation classes that are stored in this library JAR file to be automatically registered, with no action required by the application. Chapter 10 Using JSF in Web Applications 10-11 XML parsing errors detected during the loading of an application resource file are fatal to application startup, and must cause the application to not be made available by the container. Whether or not a validating parse is performed is up to the JSF implementation; it is recommended that the JSF implementation provide a configuration parameter to control whether or not validation occurs.

Reply via email to