A cosa serve WEB-INF in un'applicazione Web Java EE?

Sto lavorando su un'applicazione Web Java EE con la seguente struttura di codice sorgente:

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

Il bit che mi interessa è WEB-INF: contiene web.xmlfile XML per l'impostazione di servlet, contesti di cablaggio del bean Spring e tag e viste JSP.

Sto cercando di capire quali vincoli / definisce questa struttura. Ad esempio, i file JSP dovrebbero sempre trovarsi all'interno WEB-INFo potrebbero essere altrove? E c'è qualcos'altro che potrebbe entrare WEB-INF? La voce dei file WAR di Wikipedia menziona le classesclassi Java e i libfile JAR - non sono sicuro di aver compreso appieno quando sarebbero necessari oltre alle altre posizioni dei file di origine.

La specifica Servlet 2.4 dice questo su WEB-INF (pagina 70):

Esiste una directory speciale nella gerarchia dell'applicazione denominata WEB-INF. Questa directory contiene tutte le cose relative all'applicazione che non si trovano nella radice del documento dell'applicazione. Il WEB-INFnodo non fa parte dell'albero dei documenti pubblici dell'applicazione . Nessun file contenuto nella WEB-INFdirectory può essere servito direttamente a un client dal contenitore. Tuttavia, i contenuti della WEB-INFdirectory sono visibili al codice servlet usando le chiamate del metodo getResource e getResourceAsStreamsu ServletContext, e possono essere esposti usando le RequestDispatcherchiamate.

Ciò significa che le WEB-INFrisorse sono accessibili al caricatore di risorse dell'applicazione Web e non sono direttamente visibili al pubblico.

Questo è il motivo per cui molti progetti mettono le loro risorse come file JSP, JAR / librerie e i propri file di classe o file delle proprietà o qualsiasi altra informazione sensibile nella WEB-INFcartella. Altrimenti sarebbero accessibili usando un semplice URL statico (utile per caricare CSS o Javascript per esempio).

I tuoi file JSP possono essere ovunque anche se dal punto di vista tecnico. Ad esempio in primavera puoi configurarli per essere WEB-INFesplicitamente:

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

Le cartelle WEB-INF/classese WEB-INF/libmenzionate nell'articolo sui file WAR di Wikipedia sono esempi di cartelle richieste dalle specifiche Servlet in fase di esecuzione.

È importante fare la differenza tra la struttura di un progetto e la struttura del file WAR risultante.

La struttura del progetto rifletterà in alcuni casi parzialmente la struttura del file WAR (per risorse statiche come file JSP o file HTML e JavaScript, ma non è sempre così.

La transizione dalla struttura del progetto al file WAR risultante viene eseguita da un processo di generazione.

Mentre di solito sei libero di progettare il tuo processo di compilazione, oggigiorno la maggior parte delle persone utilizzerà un approccio standardizzato come Apache Maven . Tra le altre cose, Maven definisce i valori predefiniti per i quali le risorse nella struttura del progetto sono associate a quali risorse nell'artefatto risultante (in questo caso l'artefatto risultante è il file WAR). In alcuni casi la mappatura consiste in un semplice processo di copia, in altri casi il processo di mappatura include una trasformazione, come il filtraggio o la compilazione e altri.

Un esempio : la WEB-INF/classescartella conterrà in seguito tutte le classi e le risorse java compilate ( src/main/javae src/main/resources) che devono essere caricate dal Classloader per avviare l'applicazione.

Un altro esempio : la WEB-INF/libcartella conterrà in seguito tutti i file jar necessari all'applicazione. In un progetto maven le dipendenze sono gestite per te e maven copia automaticamente i file jar necessari nella WEB-INF/libcartella per te. Questo spiega perché non hai una libcartella in un progetto maven.

Quando si distribuisce un'applicazione Web Java EE (utilizzando framework o meno), la sua struttura deve seguire alcuni requisiti / specifiche. Queste specifiche provengono da:

• Il contenitore servlet (ad es. Tomcat)
• API servlet Java
• Il dominio della tua applicazione

1. Requisiti del contenitore servlet
   Se si utilizza Apache Tomcat, la directory principale dell'applicazione deve essere collocata nella cartella webapp. Potrebbe essere diverso se si utilizza un altro contenitore servlet o un server applicazioni.
   
   

2. Requisiti dell'API Servlet Java L'API Servlet
   Java afferma che la directory dell'applicazione radice deve avere la struttura seguente:

   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
   

Questi requisiti sono definiti dall'API Servlet Java.

3. Dominio applicazione
Dopo aver seguito i requisiti del contenitore Servlet (o del server applicazioni) e i requisiti dell'API Servlet Java, è possibile organizzare le altre parti della propria webapp in base a ciò di cui si ha bisogno.
- È possibile inserire le risorse (file JSP, file di testo semplice, file di script) nella directory principale dell'applicazione. Tuttavia, le persone possono accedervi direttamente dal proprio browser, invece che le loro richieste vengano elaborate da una logica fornita dall'applicazione. Pertanto, per impedire l'accesso diretto alle risorse in questo modo, è possibile inserirle nella directory WEB-INF, il cui contenuto è accessibile solo dal server.
-Se usi alcuni framework, usano spesso file di configurazione. La maggior parte di questi framework (struts, spring, hibernate) richiedono di inserire i loro file di configurazione nel classpath (la directory "classes").

Dovresti inserire in WEB-INF qualsiasi pagina o pezzo di pagina che non vuoi essere pubblico. Di solito, JSP o facelet si trovano all'esterno di WEB-INF, ma in questo caso sono facilmente accessibili per qualsiasi utente. Nel caso in cui abbiate alcune restrizioni di autorizzazione, WEB-INF può essere utilizzato per questo.

WEB-INF / lib può contenere librerie di terze parti che non si desidera comprimere a livello di sistema (i JAR possono essere disponibili per tutte le applicazioni in esecuzione sul server), ma solo per questa particolare applicazione.

In generale, molti file di configurazione vanno anche in WEB-INF.

Come per WEB-INF / classi - esiste in qualsiasi app web, perché quella è la cartella in cui sono posizionate tutte le fonti compilate (non JARS, ma i file .java compilati che hai scritto tu).

Questa convenzione è seguita per motivi di sicurezza. Ad esempio, se una persona non autorizzata è autorizzata ad accedere al file JSP di root direttamente dall'URL, può navigare attraverso l'intera applicazione senza alcuna autenticazione e può accedere a tutti i dati protetti.

Esiste una convenzione (non necessaria) di posizionare le pagine jsp nella directory WEB-INF in modo che non possano essere collegate in profondità o aggiunte ai segnalibri. In questo modo tutte le richieste alla pagina jsp devono essere indirizzate attraverso la nostra applicazione, in modo che l'esperienza dell'utente sia garantita.