La solita risposta a "qual è la strada giusta?" o "è questo il modo giusto?" è ..... dipende .
Tutto quello che posso fare è dirti i pro e i contro di idee specifiche. Ciò che segue è al 100% la mia opinione. Non conosco requisiti o regole specifici. Sono sicuro che qualcuno non sarà d'accordo con me.
JSP di
Lavoriamo sull'opportunità o meno di inserire JSP in WEB-INF.
Pro di mettere JSP in WEB-INF:
- Tu controlli come vengono eseguiti i JSP. Se vuoi che un JSP sia parametrizzato e riutilizzabile (il che è comunque davvero difficile con un JSP), puoi inserirli in WEB-INF e utilizzare un servlet o un controller di azione Struts o qualche altro front controller per eseguire la pre-elaborazione e quindi passare il controllo al JSP, passando nel giusto contesto di ambiente (come attributi di richiesta, eventuali controlli di sicurezza, risanamento dei parametri, ecc.)
- È possibile programmare o persino a livello di firewall o IDS bloccare le richieste HTTP a * .jsp per ridurre la probabilità che qualcuno carichi un JSP sulla radice Web e sia quindi in grado di eseguire il codice come server Web. Dovrebbero sovrascrivere un JSP esistente. Non è un enorme vantaggio in termini di sicurezza, ma rende il compromesso leggermente più difficile.
- Applica buone abitudini, come MVC, front controller, filtri servlet, iniezione di dipendenza, ecc. Al contrario di un grande mostruoso JSP che fa tutto il lavoro stesso ed è difficile da leggere / mantenere.
Contro di mettere JSP in WEB-INF:
- Non è possibile accedere direttamente alla pagina, anche se si tratta di una semplice pagina autonoma che non necessita di elaborazione anticipata. Questo perché i file in / WEB-INF non sono servibili da un contenitore servlet.
File statici
In termini di file puramente statici come HTML, immagine, foglio di stile, javascript, ecc., Posizionali sotto la radice del web (my_app nel tuo caso), ma NOT / WEB-INF (perché non è accessibile).
Layout generale
Per quanto riguarda il layout generale della directory, dipende in qualche modo dal processo di compilazione. Mi piace archiviare tutto in "src" o "source" perché chiarisce quali file vengono generati dalla costruzione e quali sono file sorgente puri. mainti permette di separare il codice di test come le classi junit dal tuo codice sorgente principale, il che è buono. Ma se non hai alcun test unitario (oh no!), Allora è una distinzione insignificante.
D'altra parte, se non si manipola affatto la radice Web durante la compilazione (come se fosse tutto JSP e file statici), allora forse lo si mantiene al livello più alto, come /webrooto /deploye si copiano i file in base alle esigenze, come File .class o .jar. È un'abitudine degli esseri umani (specialmente degli sviluppatori) organizzarsi in modo eccessivo. Un buon segno di un'eccessiva organizzazione è avere molte cartelle con una sola sottocartella.
Quello che hai mostrato
Hai indicato che stai seguendo una convenzione impostata da Maven, quindi se stai già utilizzando Maven, segui semplicemente quel layout. Non c'è assolutamente nulla di sbagliato nel layout che hai descritto.
