JSF retourne une page vierge avec une source XHTML/XML/EL au lieu de la sortie HTML rendue

j'ai des dossiers de Facelets comme ci-dessous.

WebContent
 |-- index.xhtml
 |-- register.xhtml
 |-- templates
 |    |--userForm.xhtml
 |    `--banner.xhtml
 :

les deux pages utilisent des modèles du répertoire /templates . Mon /index.xhtml s'ouvre très bien dans le navigateur. J'obtiens la sortie HTML générée. J'ai un lien dans le fichier /index.xhtml vers le fichier /register.xhtml . Cependant, mon /register.xhtml n'est pas analysé et retourne comme simple XHTML / raw XML au lieu de sa sortie HTML générée. Lorsque je clique rightclick page dans le navigateur et faire voir la page source , puis je vois toujours le code source XHTML au lieu de la sortie HTML générée. Il semble que le modèle n'est pas appliquée.

cependant, quand j'ouvre le /register.xhtml comme /faces/register.xhtml dans la barre d'adresse du navigateur, alors il affiche correctement. Comment cela est-il causé et comment puis-je le résoudre?

13
demandé sur BalusC 2010-06-24 22:41:37

1 réponses

il y a trois causes principales.

  1. FacesServlet n'est pas invoquée.
  2. Les URIs D'espace de noms
  3. XML sont manquants ou erronés.
  4. plusieurs applications JSF ont été chargées.

1. Assurez-vous que L'URL correspond à FacesServlet mapping

L'URL du lien (L'URL telle que vous la voyez dans la barre d'adresse du navigateur) doit correspondre à <url-pattern> du FacesServlet comme défini dans web.xml afin d'obtenir tous les travaux JSF à exécuter. Le FacesServlet est celui qui est responsable de l'analyse du fichier XHTML, de la collecte des valeurs des formulaires soumis, de la conversion/validation, de la mise à jour des modèles, de l'invocation des actions et de la génération de la sortie HTML. Si vous n'invoquez pas le FacesServlet par URL, alors tout ce que vous obtiendriez (et voir via rightclick, View Source dans le navigateur) est en effet le code source XHTML brut.

si le <url-pattern> est par exemple *.jsf , alors le lien doit pointer vers /register.jsf et non /register.xhtml . Si c'est par exemple /faces/* , comme vous l'avez fait, alors le lien devrait pointer /faces/register.xhtml et non /register.xhtml . Une façon d'éviter cette confusion est de simplement changer le <url-pattern> de /faces/* à *.xhtml . La carte ci-dessous est donc idéale:

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

si vous ne pouvez pas changer le <url-pattern> en *.xhtml pour une raison quelconque, alors vous aimeriez probablement aussi empêcher les utilisateurs finaux d'accéder directement aux fichiers de code source XHTML par URL. Dans ce cas, vous pouvez ajouter un <security-constraint> sur le <url-pattern> de *.xhtml vide <auth-constraint> dans web.xml qui empêche que:

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

la prochaine JSF 2.3 résoudra tout ce qui précède en enregistrant automatiquement le FacesServlet sur un patron D'URL de *.xhtml pendant le démarrage de webapp.

voir aussi:


2. Assurez-vous que les espaces de noms XML correspondent à la version JSF

depuis introduction de JSF 2.2, une autre cause probable est que les espaces de noms XML ne correspondent pas à la version JSF. Le xmlns.jcp.org comme ci-dessous est nouveau depuis JSF 2.2 et ne fonctionne pas dans les versions JSF plus anciennes. Les symptômes sont presque les mêmes que si le FacesServlet n'est pas appelé.

<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">

si vous ne pouvez pas passer à la version 2.2 de JSF, vous devez utiliser l'ancien java.sun.com XML namespaces à la place:

<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">

voir aussi:


3. Plusieurs implémentations JSF ont été chargées

une autre cause probable est que plusieurs implémentations JSF ont été chargées par votre webapp, en conflit et en se corrompant mutuellement. Par exemple, lorsque le chemin de classe runtime de votre webapp est pollué par plusieurs bibliothèques JSF différentes, ou dans le Mojarra 2 spécifique.X + Tomcat 8.combinaison de x, lorsqu'il y a une entrée ConfigureListener inutile dans le web.xml de webapp, ce qui fait qu'il est chargé deux fois.

<!-- 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>

lors de l'utilisation de Maven, faire absolument assurez-vous que vous déclarez les dépendances de la bonne façon et que vous comprenez la dépendance étendues. Il est important de ne pas empaqueter les dépendances dans webapp lorsque celles-ci sont déjà fournies par le serveur cible.

voir aussi:


assurez-vous que vous apprenez JSF de la bonne façon

JSF a une courbe d'apprentissage très raide pour ceux qui ne sont pas familiers avec la base HTTP , HTML et Servlets . Il y a beaucoup de ressources de mauvaise qualité sur Internet. S'il Vous Plaît ignorer les sites de raclage code snippet maintenus par les amateurs avec l'accent principal sur le revenu de la publicité au lieu de sur l'enseignement, comme roseindia, tutorialspoint, javabeat, etc. Ils sont facilement reconnaissables en dérangeant les liens publicitaires/bannières. Veuillez également ne pas tenir compte des ressources portant sur jurassic JSF 1.x. Ils sont facilement reconnaissables en utilisant des fichiers JSP au lieu de fichiers XHTML. La technologie JSP as view a été dépréciée depuis JSF 2.0 à 2009 déjà.

pour commencer de la bonne façon, commencez par notre page wiki JSF et commandez un Livre faisant autorité .

voir aussi:

37
répondu BalusC 2017-05-23 11:55:00