By BlueBird


2010-06-24 18:41:37 8 Comments

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?

1 comments

@BalusC 2010-06-24 20:25:47

There are three main causes.

  1. FacesServlet is not invoked.
  2. XML namespace URIs are missing or wrong.
  3. 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:


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:


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:


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, 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:

@gekrish 2010-06-25 20:57:52

+1 for Security Constraint info.

@BlueBird 2010-06-26 11:50:33

THanks BalusC. I will try this out and back to you. Keep in touch.

@BlueBird 2010-06-26 19:17:17

Hi dear, Now I added my link using <h:link /> tag. The links work fine. Still I have one question. The link is automatically go into /faces/register.xhtml . Is there any way that I can hide the /faces/ directory and link should displayed /register.xhtml without the "faces" directory???

@BalusC 2010-06-26 19:19:36

Ah, you're using prefix mapping /faces/*, no you can't hide it. Use extension mapping like *.jsf, *.faces or even *.customextension.

@BlueBird 2010-06-27 09:50:20

How to do that please?

@BalusC 2010-06-27 21:17:25

Replace /faces/* by *.jsf as url-pattern of FacesServlet.

@UnknownJoe 2017-05-22 14:48:37

Just now had another option. p:remoteCommand had an update attribute with wrong id. Maybe, it will work out for somebody.

@Kukeltje 2018-05-12 14:38:02

I'm 100% sure there is a related question of jsf tags not being rendered in 404 pages if not used correctly. Cannot seem to find it. Want to mark a question a duplicate of this 'lost' question

@BalusC 2018-05-13 08:46:09

@hagrawal 2018-05-18 18:45:08

Saved my day, sorry saved my night and that too Friday night, if we will ever met then I will buy you a beer, if you drink :)

Related Questions

Sponsored Content

3 Answered Questions

[SOLVED] Jsf pages to plain/text without header html

2 Answered Questions

[SOLVED] How do I use html5 with jsf 2 and facelets?

1 Answered Questions

1 Answered Questions

[SOLVED] JSF page not rendering as HTML

  • 2012-12-20 20:33:41
  • philfo
  • 1743 View
  • 2 Score
  • 1 Answer
  • Tags:   jsf jsf-1.2

1 Answered Questions

[SOLVED] Component Tree not expanding when using ui:debug facelet tag

1 Answered Questions

[SOLVED] <a href> link navigation doesn't detect templates in JSF 2.0 Facelets pages

  • 2011-12-13 05:30:25
  • Sergio Sanchez
  • 2503 View
  • 0 Score
  • 1 Answer
  • Tags:   jsf-2 facelets

2 Answered Questions

[SOLVED] CommandLink navigation doesn't work in JSF

Sponsored Content