2009-06-22 19 views
13

Il example documentation dice che è sufficiente posizionare i file in war/(o una sottodirectory) e dovrebbero essere accessibili dall'host (purché non siano JSP o in WEB-INF). Ad esempio, se metti foo.css in war /, dovresti poterlo accedere a http://localhost:8080/foo.css. Tuttavia, questo non funziona affatto per me. NONE dei miei file statici sono accessibili.File statici in (Java) App Engine non accessibile

I documenti su appengine-web.xml indicano che è anche possibile specificare determinati tipi come statici. Ho provato anche questo e non fa differenza.

Mi manca qualcosa di ovvio?

UPDATE: Risulta uno dei mapping nel mio web.xml era un po 'troppo aggressivo. Il seguente è stato il colpevole:

<servlet> 
    <servlet-name>Main</servlet-name> 
    <servlet-class>MainServlet</servlet-class> 
</servlet> 
<servlet-mapping> 
    <servlet-name>Main</servlet-name> 
    <url-pattern>/</url-pattern> 
</servlet-mapping> 

Sembra che sia stato afferrando tutto ciò che non è stato afferrato essere una delle altre regole, che non capisco perché non c'era * alla fine del url- modello. Sembra anche essere direttamente in contraddizione con the documentation che dice:

Nota: File statici, i file che vengono serviti pari pari per gli utenti come immagini, CSS o JavaScript, vengono gestiti separatamente dai percorsi menzionati nel descrittore di deployment . Una richiesta per un percorso URL che corrisponde a un percorso di un file in WAR considerato un file statico servirà il file, indipendentemente dal mapping di servlet e filtro nel descrittore di distribuzione. È possibile escludere file da quelli trattati come file statici utilizzando il file appengine-web.xml.

Quindi, come posso avere una regola che corrisponde alla base del mio dominio (ad esempio http://www.example.com/) e consente comunque ai file statici di filtrare?

+0

fare i campioni che vengono con il lavoro SDK? Come avviare l'applicazione. Immagino che tu abbia già controllato che i file siano davvero in guerra/ – jitter

+0

Sì, l'app del guestbook mi permette di colpire il suo file CSS bene. –

risposta

-2

Quando si utilizza per esempio Tomcat per servire i file statici uno ha per specificare i modelli di questo tipo:

<servlet-mapping> 
    <servlet-name>default</servlet-name> 
    <url-pattern>*.css</url-pattern> 
</servlet-mapping> 
<servlet-mapping> 
    <servlet-name>default</servlet-name> 
    <url-pattern>*.js</url-pattern> 
</servlet-mapping> 

Forse si potrebbe provare a fare lo stesso?

11

Prova definire manualmente i file statici in AppEngine-web.xml come

<static-files> 
    <include path="/favicon.ico" expiration="1d" /> 
    <include path="/static/**" /> 
    <include path="/**.css" />  
</static-files> 

Questo funziona per me anche con servlet come

<servlet-mapping> 
<servlet-name>testServlet</servlet-name> 
<url-pattern>/</url-pattern> 
</servlet-mapping> 

e

<servlet-mapping> 
<servlet-name>testServlet</servlet-name> 
<url-pattern>/*</url-pattern> 
</servlet-mapping> 

Vedi Static Files and Resource Files

2

... Sembra che stia afferrando tutto ciò che non è stato afferrato essere una delle altre regole, che non capisco perché non c'era * alla fine del modello di url. ...

[[Sfortunatamente, il termine "servlet predefinito" è sovraccarico per significare cose diverse, il che conduce alla confusione. Cercherò di essere chiaro.]]

L'url-pattern "/" è speciale (Rogue Wave lo chiama "mappatura predefinita").Definisce il "servlet predefinito" dell'applicazione, che viene utilizzato quando la richiesta URL non corrisponde ad altri pattern (SRV.11.2 bullet 3 e SRV 11.1 item # 4). Apparentemente, "/" viene gestito come se si specificasse "/ *".

... E sembra anche essere direttamente in contraddizione con la documentazione ...

concordato, penso che il motore app ha un bug per cui il suo non aver seguito la documentazione citata. Ecco la mia teoria di cosa sta succedendo. Poiché esiste un servlet predefinito per la tua app (risultante dalla definizione di un servlet per il modello url "/"), l'app smette di usare "predefinito" "servlet predefinito" fornito dal contenitore per le app che non definiscono il proprio "servlet predefinito" ". Il "servlet predefinito" predefinito del contenitore è ciò che fornisce il comportamento predefinito per la pubblicazione di file statici. Penso che questo sia coerente con il comportamento di alcuni contenitori.

Mi chiedo cosa succederebbe se si tentasse di specificare un servlet per un pattern URL che corrisponde a un file statico. Servirebbe il file (come indicato dai documenti) o invocherà il servlet (come indicato da questa teoria).

... Quindi, come posso avere una regola che corrisponde alla base del mio dominio (ad esempio http://www.example.com/) e consente comunque ai file statici di filtrare? ...

Se la teoria è corretta, le soluzioni fornite da Jacob (adattato per App Engine di Google) e zockman sembrano avevano lavorano - mappano i file statici a "default" del contenitore "di default servlet ".

L'unica altra idea che ho è di scrivere il "servlet predefinito" dell'app per esaminare la richiesta per vedere se la richiesta è per "/" o meno. Se è così, gestiscilo. In caso contrario, quindi (in qualche modo) invocare il "servlet predefinito" del contenitore per elaborare la richiesta (che si spera memorizzi il file). Si spera che, una volta che il file statico è stato servito una sola volta, il caching scavalcherà i servlet in futuro.

Spiacente, non posso essere più specifico o fornire il codice: non ho ancora lavorato con il motore di app di Google (ancora!).


Rif:

+1

[Questo Q & A] (http://stackoverflow.com/a/3505227/4270992) sembra essere arrivato a una pazza risposta a questo pazzo problema. – Nick

1

Mi rendo conto che questa è una domanda molto vecchia, ma mi sono imbattuto nello stesso problema. Ho inserito il mio css/*.css, js/*.css e favicon.ico in /war/static/ e ho utilizzato la direttiva public_root nel mio appengine-web.xml in modo che punti a /static. Questo ha funzionato bene sul mio server locale di sviluppo ma non quando ho caricato l'app. Liberarsi di /static e spostare tutto su un livello ha funzionato per me.

SDK v1.5.2 (Java) su Mac OSX 10.6.8 con Java SE 6 (MacOS X Default)

Problemi correlati