servlets java-ee war web-inf

servlets - ear java



¿Para qué se utiliza WEB-INF en una aplicación web Java EE? (5)

Cuando despliega una aplicación web Java EE (usando frameworks o no), su estructura debe seguir algunos requisitos / especificaciones. Estas especificaciones provienen de:

  • El contenedor del servlet (por ejemplo, Tomcat)
  • API de Java Servlet
  • Su dominio de aplicación
  1. Los requisitos del contenedor Servlet
    Si usa Apache Tomcat, el directorio raíz de su aplicación debe colocarse en la carpeta de aplicaciones Web. Eso puede ser diferente si usa otro contenedor de servlets o servidor de aplicaciones.

  2. Requisitos de Java Servlet API
    La API de Java Servlet indica que el directorio de la aplicación raíz 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 Java Servlet API.

3. Su dominio de aplicación
Ahora que ha seguido los requisitos del contenedor Servlet (o servidor de aplicaciones) y los requisitos API Java Servlet, puede organizar las otras partes de su aplicación web según lo que necesite.
- Puede poner sus recursos (archivos JSP, archivos de texto sin formato, archivos de script) en el directorio raíz de su aplicación. Pero luego, la gente puede acceder a ellos directamente desde su navegador, en lugar de que sus solicitudes sean procesadas por alguna lógica provista por su aplicación. Por lo tanto, para evitar el acceso directo a sus recursos de esa manera, puede colocarlos en el directorio WEB-INF, cuyo contenido solo es accesible para el servidor.
-Si usa algunos marcos, a menudo usan archivos de configuración. La mayoría de estos marcos (struts, spring, hibernate) requieren que coloque sus archivos de configuración en classpath (el directorio "classes").

Estoy trabajando en una aplicación web Java EE con la siguiente estructura 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

El bit que me interesa es WEB-INF : contiene web.xml , archivos XML para configurar servlets, contextos de cableado de Spring Bean y etiquetas y vistas JSP.

El título de la pregunta es básico, pero lo que intento comprender es lo que restringe / define esta estructura. Por ejemplo, ¿los archivos JSP siempre deben estar dentro de WEB-INF o pueden estar en otro lugar? ¿Y hay algo más que pueda ir en WEB-INF ? La entrada de los archivos WAR de Wikipedia menciona classes para las classes de Java y lib para los archivos JAR; no estoy seguro de haber comprendido completamente cuándo se necesitarían, además de las otras ubicaciones de los archivos fuente.


Debe colocar en WEB-INF cualquier página o fragmento de páginas que no desee que sean públicas. Por lo general, JSP o facelets se encuentran fuera de WEB-INF, pero en este caso son de fácil acceso para cualquier usuario. En caso de que tenga algunas restricciones de autorización, WEB-INF se puede usar para eso.

WEB-INF / lib puede contener bibliotecas de terceros que no desee empacar 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 general, muchos archivos de configuraciones también entran en WEB-INF.

En cuanto a WEB-INF / classes, existe en cualquier aplicación web, porque esa es la carpeta donde se ubican todas las fuentes compiladas (no JARS, sino archivos compilados .java que usted mismo ha escrito).


Esta convención se sigue por razones de seguridad. Por ejemplo, si una persona no autorizada puede acceder al archivo raíz JSP directamente desde la URL, entonces pueden navegar por toda la aplicación sin ninguna autenticación y pueden acceder a todos los datos protegidos.


Existe una convención (no necesaria) para colocar páginas jsp en el directorio WEB-INF para que no puedan vincularse ni marcarse en profundidad. De esta forma, todas las solicitudes a la página jsp deben dirigirse a través de nuestra aplicación, de modo que la experiencia del usuario esté garantizada.


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 denominada WEB-INF . Este directorio contiene todo lo relacionado con la aplicación que no está en la raíz del documento de la aplicación. El nodo WEB-INF no es parte del árbol de documentos públicos de la aplicación . Ningún archivo contenido en el directorio WEB-INF puede ser servido directamente a un cliente por el contenedor. Sin embargo, los contenidos del directorio WEB-INF son visibles para el código de servlet utilizando las llamadas al método getResource y getResourceAsStream en el ServletContext , y pueden exponerse utilizando las llamadas a RequestDispatcher .

Esto significa que WEB-INF recursos de WEB-INF son accesibles para el cargador de recursos de su Aplicación web y no son directamente visibles para el público.

Esta es la razón por la cual muchos proyectos ponen sus recursos como archivos JSP, JAR / bibliotecas y sus propios archivos de clase o de propiedad o cualquier otra información sensible en la carpeta WEB-INF . De lo contrario, serían accesibles mediante una URL estática simple (útil para cargar CSS o Javascript, por ejemplo).

Sus archivos JSP pueden estar en cualquier lugar, aunque desde una perspectiva técnica. Por ejemplo, en Spring puedes configurarlos para que estén en WEB-INF explícitamente:

<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver" p:prefix="/WEB-INF/jsp/" p:suffix=".jsp" > </bean>

Las carpetas WEB-INF/classes y WEB-INF/lib mencionadas en el artículo de archivos WAR de Wikipedia son ejemplos de carpetas requeridas por la especificación Servlet en tiempo de ejecución.

Es importante marcar la diferencia entre la estructura de un proyecto y la estructura del archivo WAR resultante.

La estructura del proyecto en algunos casos 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 usualmente eres libre de diseñar tu propio proceso de compilación, hoy en día la mayoría de la gente usa un enfoque estandarizado como Apache Maven . Entre otras cosas, Maven define los valores predeterminados para los cuales los recursos en la estructura del proyecto se asignan a los recursos en el artefacto resultante (el artefacto resultante es el archivo WAR en este caso). En algunos casos, la asignación consiste en un proceso de copia simple; en otros casos, el proceso de asignación incluye una transformación, como el filtrado o la compilación, y otros.

Un ejemplo : la carpeta WEB-INF/classes contendrá todas las clases compiladas de java y los recursos ( src/main/java y src/main/resources ) que el cargador de clases debe cargar para iniciar la aplicación.

Otro ejemplo : la carpeta WEB-INF/lib contendrá más tarde todos los archivos jar que necesita la aplicación. En un proyecto maven, las dependencias se administran por usted y maven automáticamente copia los archivos jar necesarios en la carpeta WEB-INF/lib por usted. Eso explica por qué no tienes una carpeta lib en un proyecto maven.