Cambiar el prefijo JSF al mapeo de sufijo me obliga a volver a aplicar el mapeo en imágenes de fondo CSS

He estado usando el mapeo de prefijos durante años y decidí cambiar al mapeo de sufijos, solo para deshacerme de las /faces en la url realmente. Solo quería comprobar que voy en la dirección correcta antes de cavar un agujero ya que están sucediendo algunas cosas inesperadas. Cambié de esto:

  FacesServlet /faces/*  

a esto:

  FacesServlet *.xhtml  

Y luego veo que todo lo que pasa a través de FacesServlet tiene adjunto .xhtml , de modo que el navegador está solicitando archivos background.png.xhtml , style.css.xhtml – ¿es correcto? Se llama mapeo de sufijos, supongo, pero me parece un poco desordenado y estoy tratando de convencerme de que es el camino a seguir.

En mis archivos CSS donde se hace referencia a un URI, también tengo que anexar .xhtml :

 background-image: url(images/background.png.xhtml); 

Luego vi una publicación de BalusC que ofrece una solución para evitar la descarga de recursos sin pasar por FacesServlet:

  Restrict raw XHTML docs  XHTML *.xhtml    

Cuando agrego esto, solo se .xhtml archivos .xhtml reales en la página, no se muestran todos los demás recursos (a pesar de tener adjunto .xhtml ).

Todo lo que quiero saber es:

  1. ¿Esto se .xhtml a todo lo normal (lo siento si la pregunta más tonta de los años)

  2. ¿Por qué la restricción de seguridad de ‘restringir documentos xhtml puros’ impide que se carguen recursos como CSS, JavaScript e imágenes?

Gracias por cualquier comentario. Estoy usando Mojarra 2.1.2 en Glassfish 3.1.

y luego veo que todo lo que pasa a través de FacesServlet tiene adjunto .xhtml, de modo que el navegador está solicitando archivos .png.xhtml, archivo .css.xhtml, ¿es esto correcto?

Esto solo se aplica a los recursos incluidos por y . Esto no está relacionado con el cambio en la asignación de URL. Esto está relacionado con el cambio de JSF 1.x a JSF 2.x y el cambio de y a las tags JSF2 antes mencionadas.

Para sus propios scripts, hojas de estilo y otras cosas estáticas que se deben servir desde el contenido web público, no debe agregar manualmente la extensión .xhtml . No debería necesitar cambiar nada con respecto a los recursos estáticos existentes.

Solo para imágenes de fondo CSS y otras referencias de url() en archivos CSS que se incluirán con la etiqueta (y por lo tanto no para

Imagine que tiene la siguiente estructura de carpeta de /resources :

 WebContent |-- META-INF |-- resources | `-- default | |-- images | | `-- background.png | `-- css | `-- style.css |-- WEB-INF `-- test.xhtml 

y que está incluyendo style.css en test.xhtml siguiente manera

  

entonces deberías definir la URL de la imagen de fondo de la siguiente manera

 body { background-image: url("#{resource['default:images/background.png']}"); } 

O cuando confía en la biblioteca predeterminada, por lo tanto, no está utilizando la library , entonces debería verse así:

 WebContent |-- META-INF |-- resources | |-- images | | `-- background.png | `-- css | `-- style.css |-- WEB-INF `-- test.xhtml 

test.xhtml :

  

style.css :

 body { background-image: url("#{resource['images/background.png']}"); } 

En cuanto a la restricción de seguridad, no es necesaria cuando ya está utilizando la asignación *.xhtml . La restricción de seguridad está destinada a evitar que el usuario final vea el código fuente XHTML sin procesar cuando el FacesServlet se mapea en un patrón que no sea *.xhtml . El usuario final podría ver el código fuente XHTML simplemente eliminando /faces parte de la URL en el caso de una asignación /faces/* o renombrando .jsf a .xhtml en el caso de una asignación *.jsf . Deshágase de la restricción de seguridad, en su caso empeora las cosas ya que está utilizando un mapeo *.xhtml que hace que ya sea imposible ver el código fuente XHTML sin procesar al hackear la URL.