2010-03-26 21 views
20

Ho una directory contenente un numero di file statici (* .png, * .css, ecc.).
ho pensato (erroneamente forse) che solo la creazione di una directory di file WEB-INF di mia domanda sarebbe sufficiente e sarebbe in grado di accedere ai file dal proprio riferendosi a loro per nome:
Es:Come servire contenuto statico da tomcat

<link rel="stylesheet" href="/static/styles.css" type="text/css"> 

La mia struttura di directory è la seguente:

+WEB-INF 
    | 
    +---static 
     | 
     +--styles.css 
     +--header.png 

mio web.xml è la seguente

<?xml version="1.0" encoding="ISO-8859-1"?> 
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" 
version="2.4"> 
<display-name>myapp</display-name> 
    <context-param> 
     <param-name>contextConfigLocation</param-name> 
     <param-value>classpath:com/example/myapp/spring/applicationContext.xml</param-value> 
    </context-param> 

    <listener> 
     <listener-class> 
      org.springframework.web.context.ContextLoaderListener 
     </listener-class> 
    </listener> 

    <listener> 
     <listener-class> 
      com.example.myapp.ContextListener 
     </listener-class> 
    </listener> 

    <!-- 
     There are three means to configure Wickets configuration mode and they are 
     tested in the order given. 
     1) A system property: -Dwicket.configuration 
     2) servlet specific <init-param> 
     3) context specific <context-param> 
     The value might be either "development" (reloading when templates change) 
     or "deployment". If no configuration is found, "development" is the default. 
    --> 

    <filter> 
     <filter-name>wicket.myapp</filter-name> 
     <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class> 
     <init-param> 
      <param-name>applicationFactoryClassName</param-name> 
      <param-value>org.apache.wicket.spring.SpringWebApplicationFactory</param-value> 
     </init-param> 
    </filter> 
    <filter> 
     <filter-name>wicket.session</filter-name> 
     <filter-class>org.apache.wicket.protocol.http.servlet.WicketSessionFilter</filter-class> 
     <init-param> 
      <param-name>filterName</param-name> 
      <param-value>wicket.myapp</param-value> 
     </init-param> 
    </filter> 
    <filter-mapping> 
     <filter-name>wicket.myapp</filter-name> 
     <url-pattern>/*</url-pattern> 
    </filter-mapping> 
    <filter-mapping> 
     <filter-name>wicket.session</filter-name> 
     <url-pattern>/servlet/*</url-pattern> 
    </filter-mapping> 
</web-app> 

Ma ....
Questo non funziona Ho appena ricevuto un 404 - file non trovato quando si tenta di accedere alle risorse contenute nella directory "statica". C'è qualcosa che mi manca qui?

risposta

44

Non metterli in WEB-INF, quella cartella è per il materiale che si fa non desidera essere servito direttamente.

mettere accanto al WEB-INF

+- WEB-INF 
+- static 
+1

Cosa intendi con aperto? Se è davvero necessario accedervi come file, è possibile chiedere al contenitore servlet il percorso del file system reale. – Thilo

+0

@PhilipRego Anche se è possibile (non sono sicuro che tutti i contenitori servlet lo consentano), non dovresti scrivere all'interno della directory webapp. L'intero punto di una WAR è che si dispone di un'unità di distribuzione stateless che è possibile sostituire con una versione successiva. Molto meglio scrivere qualsiasi dato sul filesystem al di fuori della tua root webapp (o anche della memoria condivisa o di un database). – Thilo

+0

Include i file in WAR a build/deploy-time: Ovviamente. Ecco a cosa serve una WAR. Ma non dovresti scrivere su file in fase di runtime. – Thilo

2

I file non devono trovarsi in WEB-INF. Devono essere posizionati direttamente all'interno della directory delle applicazioni Web o del file WAR.

Vedere il mio answer here per includere il percorso di contesto prima delle risorse statiche.

2

WEB-INF è una directory protetta. Devono essere collocati in o in una sottodirectory nella directory dell'app Web di primo livello.

Problemi correlati