La solita risposta a "qual è la strada giusta?" o "è questa la strada giusta?" è ..... dipende .
Tutto quello che posso fare è dirti i pro ei contro su idee specifiche. Quello che segue è al 100% la mia opinione. Non conosco requisiti o regole specifici. Sono sicuro che qualcuno non sarà d'accordo con me.
di JSP
Cerchiamo di mettere JSP in WEB-INF o no.
I professionisti di inserire JSP in WEB-INF:
- Controlla come vengono eseguite le JSP. Se vuoi che un JSP sia parametrizzato e riutilizzabile (che è comunque molto difficile con una JSP), puoi metterli in WEB-INF e usare 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 ambientale (come attributi di richiesta, controlli di sicurezza, sanificazione dei parametri, ecc.)
- È possibile programmare a livello di codice o anche a livello di firewall o blocco IDS richieste HTTP a * .jsp per ridurre la probabilità che qualcuno carichi un JSP nella web root e quindi sia in grado di eseguire codice come server web. Dovrebbero sovrascrivere un JSP esistente. Non un enorme vantaggio in termini di sicurezza, ma rende i compromessi leggermente più difficili.
- Applica buone abitudini, come MVC, front controller, filtri servlet, dipendenza 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 sotto / 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. inserisci quelli nella root 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 sotto "src" o "source" perché rende chiaro quali file sono generati dalla costruzione e quali sono i file di origine puri. main ti consente di separare il codice di test come le classi junit dal tuo codice sorgente principale, il che è positivo. Ma se non hai alcun test unitario (oh no!), Allora è una distinzione senza senso.
D'altra parte, se non manipoli la web root durante la compilazione (come se fosse tutto JSP e file statici), allora forse la mantieni al livello più alto, come /webroot o /deploy e copiare i file in base alle necessità, come .class o .jar file. È un'abitudine degli esseri umani (specialmente gli sviluppatori) di sovra-organizzare. Un buon segno di sovra-organizzazione sta avendo molte cartelle con una sola sottocartella.
Cosa hai mostrato
Hai indicato che stai seguendo un set di convenzioni da parte di Maven, quindi se stai già usando Maven, segui semplicemente quel layout. Non c'è assolutamente nulla di sbagliato nel layout che hai descritto.
