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ó.
