¿Para qué se utiliza WEB-INF en una aplicación web Java EE?
Estoy trabajando en una aplicación web Java EE con la siguiente estructura de directorio de código fuente:
src/main/java <-- multiple packages containing Java classes
src/test/java <-- multiple packages containing JUnit tests
src/main/resources <-- includes properties files for textual messages
src/main/webapp/resources <-- includes CSS, images and all Javascript files
src/main/webapp/WEB-INF
src/main/webapp/WEB-INF/tags
src/main/webapp/WEB-INF/views
La carpeta que me interesa es WEB-INF: Contiene web.xmlarchivos XML para configurar servlets, contextos de cableado de Spring Bean y etiquetas y vistas JSP. Estoy tratando de entender qué limita/define esta estructura. Por ejemplo, ¿los archivos JSP siempre tienen que estar dentro WEB-INFo podrían estar en otro lugar? ¿Y hay algo más que pueda entrar WEB-INF? La entrada de archivos WAR de Wikipedia menciona classesclases Java y libarchivos JAR; no estoy seguro de haber comprendido completamente cuándo serían necesarios además de las otras ubicaciones de archivos fuente.
La especificación de Servlet 2.4 dice esto sobre WEB-INF (página 70):
Existe un directorio especial dentro de la jerarquía de la aplicación llamado
WEB-INF. Este directorio contiene todo lo relacionado con la aplicación que no se encuentra en la raíz del documento de la aplicación. ElWEB-INFnodo no forma parte del árbol de documentos públicos de la aplicación .WEB-INFEl contenedor no puede entregar ningún archivo contenido en el directorio directamente a un cliente. Sin embargo, el contenido delWEB-INFdirectorio es visible para el código de servlet mediante las llamadas al métodogetResourceygetResourceAsStreamen elServletContexty puede quedar expuesto mediante lasRequestDispatcherllamadas.
Esto significa que WEB-INFlos recursos son accesibles para el cargador de recursos de su aplicación web y no visibles directamente para el público.
Es por eso que muchos proyectos colocan sus recursos como archivos JSP, JAR/bibliotecas y sus propios archivos de clase o archivos de propiedades o cualquier otra información confidencial en la WEB-INFcarpeta. De lo contrario, se podría acceder a ellos mediante una URL estática simple (útil para cargar CSS o Javascript, por ejemplo).
Desde una perspectiva técnica, sus archivos JSP pueden estar en cualquier lugar. Por ejemplo, en Spring puedes configurarlos para que estén WEB-INFexplícitamente:
<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver"
p:prefix="/WEB-INF/jsp/"
p:suffix=".jsp" >
</bean>
Las carpetas WEB-INF/classesy mencionadas en el artículo sobre archivos WAR de Wikipedia son ejemplos de carpetas requeridas por la especificación de servlet en tiempo de ejecución.WEB-INF/lib
Es importante marcar la diferencia entre la estructura de un proyecto y la estructura del archivo WAR resultante.
En algunos casos, la estructura del proyecto reflejará parcialmente la estructura del archivo WAR (para recursos estáticos como archivos JSP o archivos HTML y JavaScript, pero este no es siempre el caso).
La transición de la estructura del proyecto al archivo WAR resultante se realiza mediante un proceso de compilación.
Si bien normalmente eres libre de diseñar tu propio proceso de compilación, hoy en día la mayoría de la gente utiliza un enfoque estandarizado como Apache Maven . Entre otras cosas, Maven define valores predeterminados para qué recursos en la estructura del proyecto se asignan a qué recursos en el artefacto resultante (el artefacto resultante es el archivo WAR en este caso). En algunos casos, el mapeo consiste en un proceso de copia simple, en otros casos, el proceso de mapeo incluye una transformación, como filtrado o compilación, entre otros.
Un ejemplo : la WEB-INF/classescarpeta contendrá más tarde todas las clases y recursos java compilados ( src/main/javay src/main/resources) que el cargador de clases debe cargar para iniciar la aplicación.
Otro ejemplo : la WEB-INF/libcarpeta contendrá posteriormente todos los archivos jar que necesita la aplicación. En un proyecto de Maven, las dependencias se administran por usted y Maven copia automáticamente los archivos jar necesarios en la WEB-INF/libcarpeta. Eso explica por qué no tienes una libcarpeta en un proyecto de Maven.
Cuando implementa una aplicación web Java EE (usando marcos o no), su estructura debe seguir algunos requisitos/especificaciones. Estas especificaciones provienen de:
- El contenedor de servlets (por ejemplo, Tomcat)
- API de servlet de Java
- Su dominio de aplicación
- Los requisitos del contenedor de servlet
Si utiliza Apache Tomcat, el directorio raíz de su aplicación debe colocarse en la carpeta webapp. Esto puede ser diferente si utiliza otro contenedor de servlets o servidor de aplicaciones. Requisitos de la API de Servlet de Java
La API de Servlet de Java establece que el directorio raíz de su aplicación debe tener la siguiente estructura:ApplicationName | |--META-INF |--WEB-INF |_web.xml <-- Here is the configuration file of your web app(where you define servlets, filters, listeners...) |_classes <--Here goes all the classes of your webapp, following the package structure you defined. Only |_lib <--Here goes all the libraries (jars) your application need
Estos requisitos están definidos por la API de Java Servlet.
3. El dominio de su aplicación
Ahora que ha seguido los requisitos del contenedor de Servlet (o servidor de aplicaciones) y los requisitos de la API de Servlet de Java, puede organizar las otras partes de su aplicación web según sus necesidades.
- Puede colocar sus recursos (archivos JSP, archivos de texto sin formato, archivos de script) en el directorio raíz de su aplicación. Pero luego, las personas pueden acceder a ellos directamente desde su navegador, en lugar de que sus solicitudes sean procesadas por alguna lógica proporcionada por su aplicación. Entonces, para evitar que se acceda directamente a sus recursos de esa manera, puede colocarlos en el directorio WEB-INF, a cuyo contenido solo puede acceder el servidor.
-Si usa algunos marcos, a menudo usan archivos de configuración. La mayoría de estos marcos (struts, spring, hibernate) requieren que coloques sus archivos de configuración en el classpath (el directorio "clases").
Debe colocar en WEB-INF cualquier página o fragmento de página que no desee que sea pública. Normalmente, JSP o facelets se encuentran fuera de WEB-INF, pero en este caso son fácilmente accesibles para cualquier usuario. En caso de que tenga algunas restricciones de autorización, puede utilizar WEB-INF para ello.
WEB-INF/lib puede contener bibliotecas de terceros que no desea empaquetar a nivel del sistema (los JAR pueden estar disponibles para todas las aplicaciones que se ejecutan en su servidor), pero solo para esta aplicación en particular.
En términos generales, muchos archivos de configuración también van a WEB-INF.
En cuanto a WEB-INF/clases, existe en cualquier aplicación web, porque esa es la carpeta donde se colocan todas las fuentes compiladas (no JARS, sino archivos .java compilados que usted mismo escribió).
Esta convención se sigue por razones de seguridad. Por ejemplo, si a una persona no autorizada se le permite acceder al archivo JSP raíz directamente desde la URL, podrá navegar por toda la aplicación sin ninguna autenticación y podrá acceder a todos los datos seguros.
Nov 16 '2016 22:11
Existe una convención (no necesaria) de colocar páginas jsp en el directorio WEB-INF para que no se puedan establecer enlaces profundos ni marcarlas. De esta manera todas las solicitudes a la página jsp deben dirigirse a través de nuestra aplicación, para garantizar la experiencia del usuario.
