I've tried both org.omnifaces.resourcehandler.CDNResourceHandler and org.omnifaces.resourcehandler.UnmappedResourceHandler. It must be some misconfiguration, but I can't find what's wrong:
faces-config-xml:
<faces-config ...>
<application>
....
<resource-handler>org.omnifaces.resourcehandler.CDNResourceHandler</resource-handler>
<resource-handler>org.omnifaces.resourcehandler.UnmappedResourceHandler</resource-handler>
...
web.xml:
<web-app ...>
...
<context-param>
<param-name>org.omnifaces.CDN_RESOURCE_HANDLER_URLS</param-name>
<param-value>
ionicons:ionicons.min.css=http://code.ionicframework.com/ionicons/2.0.1/css/ionicons.min.css
</param-value>
</context-param>
...
Then on my jsf page:
<h:outputStylesheet name="ionicons.min.css" library="ionicons" />
I get no runtime warnings or errors appart from the "Resource not found" error:
Unable to find resource ionicons, ionicons.min.css
I am using mojarra 2.2.5 and tomcat 6.0.41. I've tried both omnifaces 1.7 and 1.10 (my project also uses primefaces, but I don't know if that's relevant). Any ideas on how to find what's wrong?
UnmappedResourceHandler doesn't support resource libraries. It's mentioned in the javadoc and showcase.
And the following CSS file reference (note: the library is not supported by the UnmappedResourceHandler! this is a technical limitation, just exclusively use name):
<h:outputStylesheet name="css/style.css" />
The technical limitation is that it's otherwise not possible to relatively reference resources from inside the CSS file. When using libraries, the path /ionicons would in your particular case be moved to query parameter ?ln=ionicons and then the CSS file would be looking for relative image references in the wrong relative folder /resources instead of /resources/ionicons.
Just get rid of library by moving it into the name:
<h:outputStylesheet name="ionicons/ionicons.min.css" />
<param-value>
ionicons/ionicons.min.css=http://code.ionicframework.com/ionicons/2.0.1/css/ionicons.min.css
</param-value>
Update: after all, it appears that you actually don't need CDNResourceHandler. It is primarily designed to be able to move auto-included JSF resources such as javax.faces:jsf.js of standard JSF and primefaces:jquery/jquery.js of PrimeFaces to a CDN host. Standard JSF namely doesn't offer any possibility for this.
If you actually need to reference an external CSS or JS resource, just use plain <link> or <script> instead of <h:outputStylesheet> or <h:outputScript>.
<link rel="stylesheet" href="http://cdn.example.com/style.css" />
<script src="http://cdn.example.com/script.js"></script>
If you intend to template it so that you could use target="head" of the usual JSF resource components, then declare a separate <ui:insert>. E.g. in master template
<h:head>
...
<ui:insert name="head-resources" />
</h:head>
and in template client
<ui:define name="head-resources">
...
</ui:define>
Related
I have some Facelets files like below.
WebContent
|-- index.xhtml
|-- register.xhtml
|-- templates
| |--userForm.xhtml
| `--banner.xhtml
:
Both pages are using templates from /templates directory. My /index.xhtml opens fine in browser. I get the generated HTML output. I have a link in /index.xhtml file to /register.xhtml file.
However, my /register.xhtml is not getting parsed and returns as plain XHTML / raw XML instead of its generated HTML output. All EL expressions in form of #{...} are displayed as-is instead of that their results are being printed. When I rightclick page in browser and do View page source, then I still see the original XHTML source code instead of the generated HTML output. For example, the <h:body> did not become a <body>. It looks like that the template is not being executed.
However, when I open the /register.xhtml like /faces/register.xhtml in browser's address bar, then it displays correctly. How is this caused and how can I solve it?
There are three main causes.
FacesServlet is not invoked.
XML namespace URIs are missing or wrong.
Multiple JSF implemenations have been loaded.
1. Make sure that URL matches FacesServlet mapping
The URL of the link (the URL as you see in browser's address bar) has to match the <url-pattern> of the FacesServlet as definied in web.xml in order to get all the JSF works to run. The FacesServlet is the one responsible for parsing the XHTML file, collecting submitted form values, performing conversion/validation, updating models, invoking actions and generating HTML output. If you don't invoke the FacesServlet by URL, then all you would get (and see via rightclick, View Source in browser) is indeed the raw XHTML source code.
If the <url-pattern> is for example *.jsf, then the link should point to /register.jsf and not /register.xhtml. If it's for example /faces/*, like you have, then the link should point to /faces/register.xhtml and not /register.xhtml. One way to avoid this confusion is to just change the <url-pattern> from /faces/* to *.xhtml. The below is thus the ideal mapping:
<servlet>
<servlet-name>facesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
If you can't change the <url-pattern> to *.xhtml for some reason, then you probably would also like to prevent endusers from directly accessing XHTML source code files by URL. In that case you can add a <security-constraint> on the <url-pattern> of *.xhtml with an empty <auth-constraint> in web.xml which prevents that:
<security-constraint>
<display-name>Restrict direct access to XHTML files</display-name>
<web-resource-collection>
<web-resource-name>XHTML files</web-resource-name>
<url-pattern>*.xhtml</url-pattern>
</web-resource-collection>
<auth-constraint />
</security-constraint>
JSF 2.3 which was introduced April 2017 has already solved all of above by automatically registering the FacesServlet on an URL pattern of *.xhtml during webapp's startup. The alternative is thus to simply upgrade to latest available JSF version which should be JSF 2.3 or higher. But ideally you should still explicitly register the FacesServlet on only one URL pattern of *.xhtml because having multiple possible URLs for exactly the same resource like /register.xhtml, /register.jsf, /register.faces and /faces/register.xhtml is bad for SEO.
See also:
Set default home page via <welcome-file> in JSF project
Opening JSF Facelets page shows "This XML file does not appear to have any style information associated with it."
Sometimes I see JSF URL is *.jsf, sometimes *.xhtml and sometimes /faces/*. Why?
JavaServer Faces 2.2 and HTML5 support, why is XHTML still being used
Which XHTML files do I need to put in /WEB-INF and which not?
Our servlets wiki - to learn the mandatory basics about servlets
2. Make sure that XML namespaces match JSF version
Since introduction of JSF 2.2, another probable cause is that XML namespaces don't match the JSF version. The xmlns.jcp.org like below is new since JSF 2.2 and does not work in older JSF versions. The symptoms are almost the same as if the FacesServlet is not invoked.
<html lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://xmlns.jcp.org/jsf/core"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
If you can't upgrade to JSF 2.2 or higher, then you need to use the old java.sun.com XML namespaces instead:
<html lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets">
But ideally you should always use the latest version where available.
See also:
Which XML namespace to use with JSF 2.2 and up
JSF tags not executed
Warning: This page calls for XML namespace http://xmlns.jcp.org/jsf/XXX declared with prefix XXX but no taglibrary exists for that namespace
3. Multiple JSF implementations have been loaded
One more probable cause is that multiple JSF implementations have been loaded by your webapp, conflicting and corrupting each other. For example, when your webapp's runtime classpath is polluted with multiple different versioned JSF libraries, or in the specific Mojarra 2.x + Tomcat 8.x combination, when there's an unnecessary ConfigureListener entry in webapp's web.xml causing it to be loaded twice.
<!-- You MUST remove this one from web.xml! -->
<!-- This is actually a workaround for buggy GlassFish3 and Jetty servers. -->
<!-- When leaving this in and you're targeting Tomcat, you'll run into trouble. -->
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
When using Maven, make absolutely sure that you declare the dependencies the right way and that you understand dependency scopes. Importantingly, do not bundle dependencies in webapp when those are already provided by the target server.
See also:
Configuration of com.sun.faces.config.ConfigureListener
How to properly install and configure JSF libraries via Maven?
Make sure that you learn JSF the right way
JSF has a very steep learning curve for those unfamiliar with basic HTTP, HTML and Servlets. There are a lot of low quality resources on the Internet. Please ignore code snippet scraping sites maintained by amateurs with primary focus on advertisement income instead of on teaching, such as roseindia, tutorialspoint, javabeat, baeldung, etc. They are easily recognizable by disturbing advertising links/banners. Also please ignore resources dealing with jurassic JSF 1.x. They are easily recognizable by using JSP files instead of XHTML files. JSP as view technology was deprecated since JSF 2.0 at 2009 already.
To get started the right way, start at our JSF wiki page and order an authoritative book.
See also:
Java / Jakarta EE web development, where do I start and what skills do I need?
What is the need of JSF, when UI can be achieved with JavaScript libraries such as jQuery and AngularJS
I would like to use the OmniFaces CombinedResourceHandler to stream resources in one go.
I registered it in faces-config.xml without any additional configuration parameters as described in CombinedResourceHandler documentation.
While it works fine with CSS resources, it does nothing with JavaScript resources. Here are my tests:
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com /jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:o="http://omnifaces.org/ui">
<h:head>
<title>CombinedResourceHandlerTest</title>
<h:outputStylesheet name="css/bootstrap-3.3.5/bootstrap.css"/>
<h:outputStylesheet name="css/main.css" />
<h:outputScript name="js/jquery/jquery.min.js"/>
<h:outputScript name="js/bootstrap-3.3.5/bootstrap.min.js"/>
</h:head>
<h:body>
<f:view>
<h2>CombinedResourceHandlerTest</h2>
</f:view>
</h:body>
Output:
<html xmlns="http://www.w3.org/1999/xhtml">
<head id="j_idt2">
<title>CombinedResourceHandlerTest</title>
<script type="text/javascript" src="/testApp/javax.faces.resource/js/jquery/jquery.min.js"></script>
<script type="text/javascript" src="/testApp/javax.faces.resource/js/bootstrap-3.3.5/bootstrap.min.js"></script>
<link type="text/css" rel="stylesheet" href="/testApp/javax.faces.resource/eNpLLi7WT8rPLykuKUos0DXWM9YzRfD1kouLa4BYPzcxMw_EAQCLpxEP.css?ln=omnifaces.combined&v=1480321351184">
</head>
Tried with attribute target="head":
<h:head>
<h:outputScript name="js/jquery/jquery.min.js" target="head"/>
</h:head>
...
Output: (scripts are completly missing):
<html xmlns="http://www.w3.org/1999/xhtml">
<head id="j_idt2">
<title>CombinedResourceHandlerTest</title>
<link type="text/css" rel="stylesheet" href="/testApp/javax.faces.resource/eNpLLi7WT8rPLykuKUos0DXWM9YzRfD1kouLa4BYPzcxMw_EAQCLpxEP.css?ln=omnifaces.combined&v=1480321351184">
</head>
...
</html>
The scripts are also missing when i move them on the top of the body:
<h:body>
<h:outputScript name="js/jquery/jquery.min.js" target="head"/>
....
</h:body>
After a look into the source i also tried with
<o:deferredScript name="js/jquery/jquery.min.js"/>
After inspecting the output for this case, I saw that the combinend script only contains the first script in order and the console shows "ReferenceError: OmniFaces is not defined":
<body>
<script type="text/javascript">OmniFaces.DeferredScript.add('/testApp/javax.faces.resource/eNpLL81JLE7OsMoq1s8qLE0tqoRSermZeXpZxQDDagwa.js?ln=omnifaces.combined&v=0');</script>
</body>
And I noticed, that even jsf.js is not included when having the CombinedResourceHandler active. the browser console tells "mojarra is not defined".
What am I doing wrong? Thanks in advance!
My environment is: Mojarra 2.2.12, Omnifaces 2.5.1, Tomcat 8.
I reproduced a very similar issue last weekend. The cause boiled down to that Mojarra was initialized twice on a Tomcat 8 server and thus corrupted the one and other. You can confirm this by looking at the server log and notice that among others Mojarra version, OmniFaces version and PrimeFaces version are logged twice.
Please doubleverify if you have only one Mojarra instance and that you do not have the ConfigureListener entry in web.xml like below, as it's by default autoregistered already.
<!-- You MUST remove this one from web.xml! -->
<!-- This is actually a workaround for buggy GlassFish3 and Jetty servers. -->
<!-- When leaving this in and you're targeting Tomcat, you'll run into trouble. -->
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
See also:
Configuration of com.sun.faces.config.ConfigureListener
How to properly install and configure JSF libraries via Maven?
For anyone else who runs into this issue I was also running into this issue using Jboss EAP 7.1.
I accidentally had the OmniFacesCombinedResourceHandler declared in a faces-config.xml in a Web Fragment JAR and in the faces-config.xml of the web application itself. Having this declared twice caused the same symptoms as the issue listed above. Once I removed it from the webapp faces-config.xml it started working.
I raised the issue on the OmniFaces issues to possibly detect and raise an error if this situation occurs: https://github.com/omnifaces/omnifaces/issues/504
<h:outputStylesheet library="test/css" name="style.css" />
Above code is not working in wildfly 10 with jar file jsf-impl-2.2.12-jbossorg-2.
Issue getting is:
WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-6) JSF1064: Unable to find or serve resource, style.css, from library, test/css.
Can anyone help on this ?
The value of a library attribute should not be a path but a reference to a single folder (grouping css ,js etc.) and a direct descendant of the resources folder.
So changing
<h:outputStylesheet library="test/css" name="style.css" />
to
<h:outputStylesheet library="test" name="css/style.css" />
should make it work.
Mojarra has been too liberal in this and it seems they are 'improving' things. I ran into a similar difference with the location of composite components. MyFaces did not allow paths in there as well, while Mojarra (until at least 2.2.12) still does.
For more details on best usage, see
What is the JSF resource library for and how should it be used?
I have some Facelets files like below.
WebContent
|-- index.xhtml
|-- register.xhtml
|-- templates
| |--userForm.xhtml
| `--banner.xhtml
:
Both pages are using templates from /templates directory. My /index.xhtml opens fine in browser. I get the generated HTML output. I have a link in /index.xhtml file to /register.xhtml file.
However, my /register.xhtml is not getting parsed and returns as plain XHTML / raw XML instead of its generated HTML output. All EL expressions in form of #{...} are displayed as-is instead of that their results are being printed. When I rightclick page in browser and do View page source, then I still see the original XHTML source code instead of the generated HTML output. For example, the <h:body> did not become a <body>. It looks like that the template is not being executed.
However, when I open the /register.xhtml like /faces/register.xhtml in browser's address bar, then it displays correctly. How is this caused and how can I solve it?
There are three main causes.
FacesServlet is not invoked.
XML namespace URIs are missing or wrong.
Multiple JSF implemenations have been loaded.
1. Make sure that URL matches FacesServlet mapping
The URL of the link (the URL as you see in browser's address bar) has to match the <url-pattern> of the FacesServlet as definied in web.xml in order to get all the JSF works to run. The FacesServlet is the one responsible for parsing the XHTML file, collecting submitted form values, performing conversion/validation, updating models, invoking actions and generating HTML output. If you don't invoke the FacesServlet by URL, then all you would get (and see via rightclick, View Source in browser) is indeed the raw XHTML source code.
If the <url-pattern> is for example *.jsf, then the link should point to /register.jsf and not /register.xhtml. If it's for example /faces/*, like you have, then the link should point to /faces/register.xhtml and not /register.xhtml. One way to avoid this confusion is to just change the <url-pattern> from /faces/* to *.xhtml. The below is thus the ideal mapping:
<servlet>
<servlet-name>facesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
If you can't change the <url-pattern> to *.xhtml for some reason, then you probably would also like to prevent endusers from directly accessing XHTML source code files by URL. In that case you can add a <security-constraint> on the <url-pattern> of *.xhtml with an empty <auth-constraint> in web.xml which prevents that:
<security-constraint>
<display-name>Restrict direct access to XHTML files</display-name>
<web-resource-collection>
<web-resource-name>XHTML files</web-resource-name>
<url-pattern>*.xhtml</url-pattern>
</web-resource-collection>
<auth-constraint />
</security-constraint>
JSF 2.3 which was introduced April 2017 has already solved all of above by automatically registering the FacesServlet on an URL pattern of *.xhtml during webapp's startup. The alternative is thus to simply upgrade to latest available JSF version which should be JSF 2.3 or higher. But ideally you should still explicitly register the FacesServlet on only one URL pattern of *.xhtml because having multiple possible URLs for exactly the same resource like /register.xhtml, /register.jsf, /register.faces and /faces/register.xhtml is bad for SEO.
See also:
Set default home page via <welcome-file> in JSF project
Opening JSF Facelets page shows "This XML file does not appear to have any style information associated with it."
Sometimes I see JSF URL is *.jsf, sometimes *.xhtml and sometimes /faces/*. Why?
JavaServer Faces 2.2 and HTML5 support, why is XHTML still being used
Which XHTML files do I need to put in /WEB-INF and which not?
Our servlets wiki - to learn the mandatory basics about servlets
2. Make sure that XML namespaces match JSF version
Since introduction of JSF 2.2, another probable cause is that XML namespaces don't match the JSF version. The xmlns.jcp.org like below is new since JSF 2.2 and does not work in older JSF versions. The symptoms are almost the same as if the FacesServlet is not invoked.
<html lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://xmlns.jcp.org/jsf/core"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
If you can't upgrade to JSF 2.2 or higher, then you need to use the old java.sun.com XML namespaces instead:
<html lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets">
But ideally you should always use the latest version where available.
See also:
Which XML namespace to use with JSF 2.2 and up
JSF tags not executed
Warning: This page calls for XML namespace http://xmlns.jcp.org/jsf/XXX declared with prefix XXX but no taglibrary exists for that namespace
3. Multiple JSF implementations have been loaded
One more probable cause is that multiple JSF implementations have been loaded by your webapp, conflicting and corrupting each other. For example, when your webapp's runtime classpath is polluted with multiple different versioned JSF libraries, or in the specific Mojarra 2.x + Tomcat 8.x combination, when there's an unnecessary ConfigureListener entry in webapp's web.xml causing it to be loaded twice.
<!-- You MUST remove this one from web.xml! -->
<!-- This is actually a workaround for buggy GlassFish3 and Jetty servers. -->
<!-- When leaving this in and you're targeting Tomcat, you'll run into trouble. -->
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
When using Maven, make absolutely sure that you declare the dependencies the right way and that you understand dependency scopes. Importantingly, do not bundle dependencies in webapp when those are already provided by the target server.
See also:
Configuration of com.sun.faces.config.ConfigureListener
How to properly install and configure JSF libraries via Maven?
Make sure that you learn JSF the right way
JSF has a very steep learning curve for those unfamiliar with basic HTTP, HTML and Servlets. There are a lot of low quality resources on the Internet. Please ignore code snippet scraping sites maintained by amateurs with primary focus on advertisement income instead of on teaching, such as roseindia, tutorialspoint, javabeat, baeldung, etc. They are easily recognizable by disturbing advertising links/banners. Also please ignore resources dealing with jurassic JSF 1.x. They are easily recognizable by using JSP files instead of XHTML files. JSP as view technology was deprecated since JSF 2.0 at 2009 already.
To get started the right way, start at our JSF wiki page and order an authoritative book.
See also:
Java / Jakarta EE web development, where do I start and what skills do I need?
What is the need of JSF, when UI can be achieved with JavaScript libraries such as jQuery and AngularJS
I have some Facelets files like below.
WebContent
|-- index.xhtml
|-- register.xhtml
|-- templates
| |--userForm.xhtml
| `--banner.xhtml
:
Both pages are using templates from /templates directory. My /index.xhtml opens fine in browser. I get the generated HTML output. I have a link in /index.xhtml file to /register.xhtml file.
However, my /register.xhtml is not getting parsed and returns as plain XHTML / raw XML instead of its generated HTML output. All EL expressions in form of #{...} are displayed as-is instead of that their results are being printed. When I rightclick page in browser and do View page source, then I still see the original XHTML source code instead of the generated HTML output. For example, the <h:body> did not become a <body>. It looks like that the template is not being executed.
However, when I open the /register.xhtml like /faces/register.xhtml in browser's address bar, then it displays correctly. How is this caused and how can I solve it?
There are three main causes.
FacesServlet is not invoked.
XML namespace URIs are missing or wrong.
Multiple JSF implemenations have been loaded.
1. Make sure that URL matches FacesServlet mapping
The URL of the link (the URL as you see in browser's address bar) has to match the <url-pattern> of the FacesServlet as definied in web.xml in order to get all the JSF works to run. The FacesServlet is the one responsible for parsing the XHTML file, collecting submitted form values, performing conversion/validation, updating models, invoking actions and generating HTML output. If you don't invoke the FacesServlet by URL, then all you would get (and see via rightclick, View Source in browser) is indeed the raw XHTML source code.
If the <url-pattern> is for example *.jsf, then the link should point to /register.jsf and not /register.xhtml. If it's for example /faces/*, like you have, then the link should point to /faces/register.xhtml and not /register.xhtml. One way to avoid this confusion is to just change the <url-pattern> from /faces/* to *.xhtml. The below is thus the ideal mapping:
<servlet>
<servlet-name>facesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
If you can't change the <url-pattern> to *.xhtml for some reason, then you probably would also like to prevent endusers from directly accessing XHTML source code files by URL. In that case you can add a <security-constraint> on the <url-pattern> of *.xhtml with an empty <auth-constraint> in web.xml which prevents that:
<security-constraint>
<display-name>Restrict direct access to XHTML files</display-name>
<web-resource-collection>
<web-resource-name>XHTML files</web-resource-name>
<url-pattern>*.xhtml</url-pattern>
</web-resource-collection>
<auth-constraint />
</security-constraint>
JSF 2.3 which was introduced April 2017 has already solved all of above by automatically registering the FacesServlet on an URL pattern of *.xhtml during webapp's startup. The alternative is thus to simply upgrade to latest available JSF version which should be JSF 2.3 or higher. But ideally you should still explicitly register the FacesServlet on only one URL pattern of *.xhtml because having multiple possible URLs for exactly the same resource like /register.xhtml, /register.jsf, /register.faces and /faces/register.xhtml is bad for SEO.
See also:
Set default home page via <welcome-file> in JSF project
Opening JSF Facelets page shows "This XML file does not appear to have any style information associated with it."
Sometimes I see JSF URL is *.jsf, sometimes *.xhtml and sometimes /faces/*. Why?
JavaServer Faces 2.2 and HTML5 support, why is XHTML still being used
Which XHTML files do I need to put in /WEB-INF and which not?
Our servlets wiki - to learn the mandatory basics about servlets
2. Make sure that XML namespaces match JSF version
Since introduction of JSF 2.2, another probable cause is that XML namespaces don't match the JSF version. The xmlns.jcp.org like below is new since JSF 2.2 and does not work in older JSF versions. The symptoms are almost the same as if the FacesServlet is not invoked.
<html lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://xmlns.jcp.org/jsf/core"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
If you can't upgrade to JSF 2.2 or higher, then you need to use the old java.sun.com XML namespaces instead:
<html lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets">
But ideally you should always use the latest version where available.
See also:
Which XML namespace to use with JSF 2.2 and up
JSF tags not executed
Warning: This page calls for XML namespace http://xmlns.jcp.org/jsf/XXX declared with prefix XXX but no taglibrary exists for that namespace
3. Multiple JSF implementations have been loaded
One more probable cause is that multiple JSF implementations have been loaded by your webapp, conflicting and corrupting each other. For example, when your webapp's runtime classpath is polluted with multiple different versioned JSF libraries, or in the specific Mojarra 2.x + Tomcat 8.x combination, when there's an unnecessary ConfigureListener entry in webapp's web.xml causing it to be loaded twice.
<!-- You MUST remove this one from web.xml! -->
<!-- This is actually a workaround for buggy GlassFish3 and Jetty servers. -->
<!-- When leaving this in and you're targeting Tomcat, you'll run into trouble. -->
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
When using Maven, make absolutely sure that you declare the dependencies the right way and that you understand dependency scopes. Importantingly, do not bundle dependencies in webapp when those are already provided by the target server.
See also:
Configuration of com.sun.faces.config.ConfigureListener
How to properly install and configure JSF libraries via Maven?
Make sure that you learn JSF the right way
JSF has a very steep learning curve for those unfamiliar with basic HTTP, HTML and Servlets. There are a lot of low quality resources on the Internet. Please ignore code snippet scraping sites maintained by amateurs with primary focus on advertisement income instead of on teaching, such as roseindia, tutorialspoint, javabeat, baeldung, etc. They are easily recognizable by disturbing advertising links/banners. Also please ignore resources dealing with jurassic JSF 1.x. They are easily recognizable by using JSP files instead of XHTML files. JSP as view technology was deprecated since JSF 2.0 at 2009 already.
To get started the right way, start at our JSF wiki page and order an authoritative book.
See also:
Java / Jakarta EE web development, where do I start and what skills do I need?
What is the need of JSF, when UI can be achieved with JavaScript libraries such as jQuery and AngularJS