JSF devuelve una página en blanco / sin analizar con fuente XHTML / XML / EL sin formato / sin formato en lugar de una salida HTML procesada

Tengo algunos archivos Facelets como a continuación.

 Contenido web
  | - index.xhtml
  | - register.xhtml
  | - plantillas
  |  | --userForm.xhtml
  |  `--banner.xhtml
  :

Ambas páginas usan plantillas del directorio /templates . Mi /index.xhtml abre bien en el navegador. Obtengo el resultado HTML generado. Tengo un enlace en el archivo /register.xhtml en /register.xhtml . Sin embargo, mi /register.xhtml no se analiza y devuelve como XHTML simple / XML sin formato en lugar de su resultado HTML generado. Cuando hago clic con el botón derecho en la página en el navegador y veo Ver fuente de la página , aún veo el código fuente XHTML en lugar de la salida HTML generada. Parece que la plantilla no se está aplicando.

Sin embargo, cuando abro /register.xhtml como /faces/register.xhtml en la barra de direcciones del navegador, se muestra correctamente. ¿Cómo es esto causado y cómo puedo resolverlo?

Hay tres causas principales.

  1. FacesServlet no se invoca.
  2. Los URI de espacio de nombres XML faltan o son incorrectos.
  3. Se han cargado múltiples implementaciones de JSF.

1. Asegúrese de que la URL coincida FacesServlet asignación de FacesServlet

La URL del enlace (la URL como se ve en la barra de direcciones del navegador) tiene que coincidir con el de FacesServlet como FacesServlet en web.xml para poder ejecutar todas las obras de JSF. FacesServlet es el responsable de analizar el archivo XHTML, recostackr los valores de formulario enviados, realizar conversiones / validaciones, actualizar modelos, invocar acciones y generar resultados HTML. Si no FacesServlet el FacesServlet por URL, entonces todo lo que obtendrías (y verás a través del botón derecho, Ver código fuente en el navegador) es sin duda el código fuente XHTML puro.

Si el es, por ejemplo, *.jsf , entonces el enlace debe apuntar a /register.jsf y no a /register.xhtml . Si es por ejemplo /faces/* , como lo ha hecho, entonces el enlace debe apuntar a /faces/register.xhtml y no a /register.xhtml . Una forma de evitar esta confusión es cambiar el de /faces/* a *.xhtml . El siguiente es el mapeo ideal:

  facesServlet javax.faces.webapp.FacesServlet   facesServlet *.xhtml  

Si no puede cambiar el a *.xhtml por algún motivo, entonces probablemente también desee evitar que los usuarios finales accedan directamente a los archivos de código fuente XHTML por URL. En ese caso, puede agregar una en el de *.xhtml con un vacío en web.xml que impida eso:

  Restrict direct access to XHTML files  XHTML files *.xhtml    

El próximo JSF 2.3 resolverá todo lo anterior al registrar automáticamente FacesServlet en un patrón de URL de *.xhtml durante el inicio de la aplicación.

Ver también:

  • Establecer la página de inicio predeterminada a través de en el proyecto JSF
  • Apertura de errores de página de Facelets con “Este archivo XML no parece tener ninguna información de estilo asociada a él”.
  • Facelets JSF: A veces veo que la URL es .jsf y, a veces, .xhtml. ¿Por qué?
  • Soporte de JavaServer Faces 2.2 y HTML5, ¿por qué XHTML todavía se está utilizando?
  • ¿Qué archivos XHTML necesito poner / WEB-INF y cuáles no?
  • Nuestra wiki servlets – para aprender los conceptos básicos obligatorios sobre los servlets

2. Asegúrese de que los espacios de nombres XML coincidan con la versión JSF

Desde la introducción de JSF 2.2, otra causa probable es que los espacios de nombres XML no coinciden con la versión JSF. El siguiente xmlns.jcp.org es nuevo desde JSF 2.2 y no funciona en versiones anteriores de JSF. Los síntomas son casi los mismos que si FacesServlet no se invoca.

  

Si no puede actualizar a JSF 2.2, debe usar los espacios de nombres XML java.sun.com antiguos en su lugar:

  

Ver también:

  • Qué espacio de nombres XML usar con JSF 2.2
  • Etiquetas JSF no ejecutadas
  • Advertencia: esta página requiere el espacio de nombres XML http://xmlns.jcp.org/jsf/XXX declarado con el prefijo XXX pero no existe una taglibrary para ese espacio de nombres

3. Se han cargado múltiples implementaciones JSF

Una causa más probable es que su aplicación web ha cargado varias implementaciones JSF, que entran en conflicto y se corrompían entre sí. Por ejemplo, cuando el classpath de tiempo de ejecución de su webapp está contaminado con múltiples bibliotecas JSF versionadas diferentes, o en la combinación específica de Mojarra 2.x + Tomcat 8.x, cuando hay una entrada innecesaria de ConfigureListener en el web.xml de web.xml que hace que se cargue dos veces.

     com.sun.faces.config.ConfigureListener  

Cuando utilice Maven, asegúrese de declarar las dependencias de la manera correcta y de comprender los ámbitos de dependencia. Importantemente, no agrupe las dependencias en la aplicación web cuando ya las proporciona el servidor de destino.

Ver también:

  • Configuración de com.sun.faces.config.ConfigureListener
  • ¿Cómo instalar y configurar correctamente las bibliotecas JSF a través de Maven?

Asegúrate de aprender JSF de la manera correcta

JSF tiene una curva de aprendizaje muy empinada para aquellos que no están familiarizados con HTTP , HTML y Servlets básicos. Hay muchos recursos de baja calidad en Internet. Por favor, ignore los sitios de raspado de fragmentos de código mantenidos por aficionados con un enfoque principal en los ingresos publicitarios en lugar de en la enseñanza, como roseindia, tutorialspoint, javabeat, etc. Son fácilmente reconocibles por molestos enlaces publicitarios / banners. Igualmente, ignore los recursos que tratan con Jurásico JSF 1.x. Son fácilmente reconocibles mediante el uso de archivos JSP en lugar de archivos XHTML. JSP ya que la tecnología de visualización ya no está disponible desde JSF 2.0 en 2009.

Para comenzar de la manera correcta, comience en nuestra página wiki de JSF y solicite un libro autorizado .

Ver también:

  • Desarrollo web Java EE, ¿dónde empiezo y qué habilidades necesito?
  • ¿Cuál es la necesidad de JSF, cuando la IU se puede lograr desde CSS, HTML, JavaScript, jQuery?