Opening JSF Facelets page shows "This XML file does not appear to have any style information associated with it."

Question

I'm trying to run my Eclipse JSF project on Apache Tomcat on other computer. I created a WAR file with this tutorial. However, when I deploy the WAR and open the Facelet page in Firefox, I'm getting only the following error message:

This XML file does not appear to have any style information associated with it. The document tree is shown below.

This my first time when I try run my JSF app without Eclipse. How is this caused and how can I solve it?

I'm actually trying to open the following Facelet page:

<?xml version="1.0" encoding="UTF-8"?>
<ui:composition template="/WEB-INF/templates/template_a.xhtml"
    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">
    <ui:define name="title">
        tytol
    </ui:define>
</ui:composition>

Clardy

It doesn't look like a JSF nor eclipse problem, it's more related to some XML file in your project. – Barclay

Why are you creating a war file by hand and with that tutorial in particular? Use this one instead: help.eclipse.org/helios/… – Phreno

if this a is jsf problem what may cause it? App works fine in eclipse. – Clardy

@Kukeltje This question isn't about Facelets specifically. It's about why XML appears that way in the browser – Lui

it is browser specific – Poisonous

Answer 1

This XML file does not appear to have any style information associated with it. The document tree is shown below.

You will get this message in the client side when the client (the web browser) for some reason interprets the HTTP response content representing a HTML document as text/xml instead of text/html and the parsed XML tree doesn't have any XML-stylesheet. In other words, the web browser parsed the retrieved HTTP response content as XML instead of as HTML due to a missing or incorrect HTTP response content type.

In case of JSF/Facelets files which have the default extension of .xhtml, that can in turn happen if the HTTP request hasn't invoked the FacesServlet and thus it wasn't able to parse the Facelets file and generate the desired HTML output based on the XHTML source code. Firefox is then merely guessing the HTTP response content type based on the .xhtml file extension which is in your Firefox configuration apparently by default interpreted as text/xml.

You need to make sure that the HTTP request URL, as you see in browser's address bar, matches the <url-pattern> of the FacesServlet as registered in webapp's web.xml, so that it will be invoked and be able to generate the desired HTML output based on the XHTML source code. If it's for example *.jsf, then you need to open the page by /some.jsf instead of /some.xhtml. Alternatively, you can also just change the <url-pattern> to *.xhtml. This way you never need to fiddle with virtual URLs.

See also:

• Sometimes I see JSF URL is *.jsf, sometimes *.xhtml and sometimes /faces/*. Why?
• JSF returns blank/unparsed page with plain/raw XHTML/XML/EL source instead of rendered HTML output

---

Note thus that you don't actually need a XML stylesheet. In your specific case it was just a misinterpretation from the webbrowser while trying to do its best to make something presentable out of the retrieved HTTP response content.

Withershins

I'm facing the same issue, I have <url-pattern>*.jsf</url-pattern> and when I tried to access myPage.jsf (after an interruption -server down then up- ) I get the same error + in the server logs : ERROR: MAC did not verify! – Diversify

I am also having the same issue. In my web.xml I have <servlet-mapping> <servlet-name>Faces Servlet</servlet-name> <url-pattern>*.jsf</url-pattern> </servlet-mapping>, however trying to invoke a http://.....objektAnlegen.jsf request gives me the error message above. So, the problem is somewhere else. – Eo

@Alex: The first paragraph explains why this will happen. The second paragraph explains one possible cause. The third paragraph explains the solution to this possible cause. If this possible cause does not match your situation then you need to re-read the first paragraph and track back why exactly the browser interprets your HTTP response as text/xml instead of text/html. In other words, simply debug the HTTP response with this information in mind. – Withershins

Answer 2

Add xmlns="http://www.w3.org/2000/svg" atrribute to the begining of the svg tag like this: <svg xmlns="http://www.w3.org/2000/svg"

Infeld