Estructura de carpetas de aplicaciones web Java

Como principiante en J2EE, recientemente comencé a desarrollar mi propio proyecto desde cero utilizando el Core de J2EE: Servlets & Jsps.

No pude evaluar si la estructura de la carpeta de mi proyecto es correcta o no. Aquí está mi estructura de carpetas del proyecto.

Antes de hacer una pregunta, admito que no podría responder ni justificar si alguien me pregunta por qué este tipo de estructura de carpetas. La pregunta: ¿es una buena señal poner mis jsps fuera de web-inf. Si no, ¿por qué es así? ¿Si es así por qué?

¿Existe alguna convención de estructura de carpetas estándar para una aplicación web J2EE? Sé que Maven ha presentado algunos estándares, pero aún así, podemos personalizar según el requisito que creo.

He buscado un poco en Google y he encontrado las dos referencias 1 2

donde en las respuestas no están en la misma página, de las cuales no pude sacar ninguna conclusión.

¿Cuáles son los puntos a tener en cuenta al diseñar la estructura de carpetas para una aplicación web J2EE, sobre todo dónde deberían ir los Jsps, el contenido estático y por qué?

La estructura estándar para un archivo WAR es:

/META-INF
   Standard jar stuff like manifest.xml
/WEB-INF
  web.xml
  /classes
    /com...etc.
  /lib

Maven genera esto para usted usando su src / main / java, recursos, webapp y sus dependencias (colocándolos en / lib) en el complemento maven-webapp , pero eso es implementación. Lo importante es darse cuenta de que todo lo que ponga en WEB-INF no es accesible externamente , mientras que todo en el directorio raíz de WAR es público.

En general, no desea poner mucho en la raíz, ya que desea que su aplicación maneje todos los accesos usando los servlets y filtros que defina en web.xml. Es común ver un index.html (o .jsp) en la raíz que redirige a un servlet, por ejemplo, una acción Struts .

Las implementaciones típicas de MVC, como Stripes o Struts, recomiendan que los usuarios no accedan a JSP directamente, prefiriendo que las JSP sean de solo lectura. Recomiendan crear controladores que reenvíen a JSP después de procesar la solicitud, y los JSP simplemente representan el resultado. Por ejemplo, al enviar un formulario, /loginse ejecutará una acción que procesa la solicitud de inicio de sesión, crea la sesión del usuario y lo reenvía a la vista de inicio de sesión de la página de inicio JSP.

La respuesta habitual a "¿cuál es la forma correcta?" o "¿es esta la forma correcta?" ..... es que depende .

Todo lo que puedo hacer es contarte los pros y los contras de ideas específicas. Lo que sigue es 100% mi opinión. No conozco ningún requisito o norma específica. Estoy seguro de que alguien no estará de acuerdo conmigo.

JSP's

Trabajemos sobre si poner JSP en WEB-INF o no.

Ventajas de poner JSP en WEB-INF:

• Usted controla cómo se ejecutan los JSP. Si desea que un JSP sea parametrizado y reutilizable (lo cual es realmente difícil con un JSP de todos modos), puede ponerlo en WEB-INF y usar un servlet o un controlador de acción Struts o algún otro controlador frontal para hacer el preprocesamiento y luego pasar el control al JSP, pasando el contexto de entorno correcto (como atributos de solicitud, cualquier verificación de seguridad, saneamiento de parámetros, etc.)
• Puede programar, o incluso a nivel de firewall o IDS, bloquear las solicitudes HTTP a * .jsp para reducir la probabilidad de que alguien cargue un JSP en la raíz web y luego pueda ejecutar el código como servidor web. Tendrían que sobrescribir un JSP existente. No es una gran ganancia de seguridad, pero hace que el compromiso sea un poco más difícil.
• Aplica buenos hábitos, como MVC, controlador frontal, filtros de servlet, inyección de dependencia, etc., a diferencia de un gran JSP monstruoso que hace todo el trabajo y es difícil de leer / mantener.

Contras de poner JSP's en WEB-INF:

• No puede acceder a la página directamente, incluso si se trata de una página independiente simple que no necesita procesamiento inicial. Esto se debe a que los archivos bajo / WEB-INF no pueden ser servidos por un contenedor de servlet.

Archivos estáticos

En términos de archivos puramente estáticos como HTML, imagen, hoja de estilo, javascript, etc., póngalos en la raíz web (my_app en su caso), pero NO / WEB-INF (porque no es accesible).

Diseño general

En cuanto al diseño general del directorio, depende un poco de su proceso de compilación. Me gusta almacenar todo bajo "src" o "fuente" porque deja en claro qué archivos se generan al compilar y cuáles son archivos de origen puro. mainle permite separar el código de prueba como las clases junit de su código fuente principal, lo cual también es bueno. Pero si no tienes pruebas unitarias (¡oh no!), Entonces es una distinción sin sentido.

Por otro lado, si no manipula la raíz web en absoluto durante la compilación (como si se tratara de archivos JSP y estáticos), tal vez lo mantenga en el nivel superior, como /webrooto /deployy copie los archivos según sea necesario, como .class o archivos .jar. Es un hábito de los seres humanos (especialmente los desarrolladores) organizarse en exceso. Una buena señal de sobreorganización es tener muchas carpetas con una sola subcarpeta.

Lo que has mostrado

Has indicado que estás siguiendo una convención establecida por maven, así que si ya estás usando maven, solo quédate con ese diseño. No hay absolutamente nada de malo en el diseño que describió.

Bueno, su src / main / webapp seguramente me recuerda a un proyecto maven. Lo que es bueno.

Sin embargo, para my_app / jsps no estoy seguro. Los desarrolladores generalmente dejan su jsp en la carpeta webapp, o si quieres hacer un poco de mapeo de url, en un directorio webapp / jsp.

!¡Advertencia! : Nunca debe poner un archivo jsp en web-inf. Su WEB-INF solo debe contener archivos xml para configurar su sitio web. Recuerde, su jsp es una página web o parte de una página web.

Puede usar el nombre de las carpetas como plantilla, parcial ... lo que le parezca bien. Debería ser fácil de encontrar para un extraño. Simplemente separe diferentes tipos de contenido como páginas completas, plantillas, vistas parciales ...

Estoy de acuerdo con Brice . También soy principiante en J2EE, pero creo que es mejor trabajar fácil y claramente al principio.

La carpeta raíz es WEBAPP, y debe hacer que su estructura web piense que la mayoría de las páginas se ubicarán allí. Si no, cuando las páginas se comunican entre ellas, probablemente no pueda administrar las relaciones de archivos sin errores.

En realidad, la aplicación WAR se puede construir sin WEB-INF/web.xml. Es posible hacer una aplicación WAR con solo clases Java dentro.

Fuente: Elementos del descriptor de implementación web.xml

Con las anotaciones Java EE, el descriptor de implementación estándar web.xml es opcional. De acuerdo con la especificación del servlet 3.0 en http://jcp.org/en/jsr/detail?id=315 , se pueden definir anotaciones en ciertos componentes web, como servlets, filtros, escuchas y manejadores de etiquetas.

Entonces, hoy en día es posible construir WAR que parece JAR con .warextensiones :)

Respondiendo a su pregunta, la estructura de WAR depende de sus requisitos.

http://en.wikipedia.org/wiki/WAR_(Sun_file_format)