2009-06-22 18 views
13

El example documentation dice que simplemente necesita colocar sus archivos en war/(o en un subdirectorio) y que deben ser accesibles desde el host (siempre que no sean JSP o en WEB-INF). Por ejemplo, si coloca foo.css en guerra/entonces debería poder acceder al http://localhost:8080/foo.css. Sin embargo, esto no funciona para mí en absoluto. NINGUNO de mis archivos estáticos son accesibles.Archivos estáticos en (Java) App Engine no accesible

Los documentos en appengine-web.xml dicen que también puede indicar específicamente ciertos tipos como estáticos. He intentado esto también y no hace la diferencia.

¿Me falta algo obvio?

ACTUALIZACIÓN: Resulta que una de las asignaciones en mi web.xml era un poco demasiado agresivo. El siguiente fue el culpable:

<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> 

Parece que estaba agarrando todo lo que no se tomó como una de las otras reglas, que no entiendo porque no había * en el extremo de la URL- patrón. También parece estar directamente contradictorio con the documentation que dice:

Nota: archivos estáticos, los archivos que se sirven textualmente a los usuarios, tales como imágenes, CSS o JavaScript, son manejados por separado de los caminos mencionados en el descriptor de despliegue . Una solicitud de una ruta de URL que coincida con una ruta a un archivo en el WAR que se considera un archivo estático servirá al archivo, independientemente de las asignaciones de servlet y filtro en el descriptor de implementación. Puede excluir archivos de aquellos tratados como archivos estáticos utilizando el archivo appengine-web.xml.

Así que, ¿cómo puedo tener una regla que coincide con la base de mi dominio (por ejemplo. http://www.example.com/) y todavía permite que los archivos estáticos para filtrar a través?

+0

¿Las muestras que vienen con el trabajo SDK? ¿Cómo se lanza la aplicación? Supongo que ya has comprobado que los archivos están realmente en guerra/ – jitter

+0

Sí, la aplicación del libro de visitas me permite acceder a su archivo CSS sin problemas. –

Respuesta

-2

Cuando se utiliza por ejemplo Tomcat para servir archivos estáticos que uno ha de especificar los patrones como este:

<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> 

Tal vez usted podría tratar de hacer lo mismo?

11

Tratar de definir manualmente los archivos estáticos en appengine-web.xml como

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

Esto funciona para mí, incluso con los servlets como

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

y

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

Ver Static Files and Resource Files

2

... Parece que estaba agarrando todo lo que no fue agarrado sea una de las otras reglas, que no entiendo porque no había * al final del patrón de url. ...

[[Desafortunadamente, el término "servlet predeterminado" está sobrecargado para significar cosas diferentes, lo que genera confusión. Trataré de ser claro.]]

El url-pattern "/" es especial (Rogue Wave lo llama el "mapeo predeterminado").Esto define el "servlet predeterminado" de la aplicación, que se utiliza cuando la solicitud de URL no coincide con otros patrones (SRV.11.2 bullet 3 y SRV 11.1 item # 4). Aparentemente, "/" se maneja como si hubiera especificado "/ *".

... También parece estar directamente en contradicción con la documentación ...

estuvo de acuerdo, creo motor de aplicación tiene un error así que no es siguiendo la documentación que se cita. Aquí está mi teoría de lo que está pasando. Dado que hay un servlet predeterminado para su aplicación (que resulta de definir un servlet para el patrón de url "/"), la aplicación deja de usar el "predeterminado" "servlet predeterminado" provisto por el contenedor para aplicaciones que no definen su propio "servlet predeterminado" ". El "servlet por defecto" del contenedor "predeterminado" es lo que proporciona el comportamiento predeterminado para servir archivos estáticos. Creo que esto es coherente con el comportamiento de algunos contenedores.

Me pregunto qué pasaría si intentara especificar un servlet para un patrón de URL que coincida con un archivo estático. Serviría el archivo (como lo indican los documentos) o invocar el servlet (como lo indica esta teoría).

... Así que, ¿cómo puedo tener una regla que coincide con la base de mi dominio (por ejemplo. http://www.example.com/) y todavía permite que los archivos estáticos a filtrar a través de? ...

Si la teoría es correcta, las soluciones aportadas por Jacob (adaptado para el motor de aplicación de Google) y zockman parecen como si hubieran funcionan - se asignan los archivos estáticos en "default" del contenedor "servlet por defecto ".

La única otra idea que tengo es escribir el "servlet predeterminado" de su aplicación para examinar la solicitud para ver si la solicitud es para "/" o no. Si es así, manejarlo. De lo contrario, invoque (de alguna manera) el "servlet por defecto" del contenedor "predeterminado" para procesar la solicitud (que con suerte almacenará en caché el archivo). Con suerte, una vez que el archivo estático se haya servido una vez, el almacenamiento en caché omitirá los servlets en el futuro.

Lo siento, no puedo ser más específico ni proporcionar código. No he trabajado con el motor de la aplicación de Google (¡aún!).


Ref:

+1

[Este Q & A] (http://stackoverflow.com/a/3505227/4270992) parece haber llegado a una respuesta loca a este problema loco. – Nick

1

Me doy cuenta de que esta es una pregunta muy antigua, pero me encontré con el mismo problema. Había puesto mi css/*.css, js/*.css y favicon.ico bajo /war/static/ y usé la directiva public_root en mi appengine-web.xml para señalar a /static. Esto funcionó bien en mi servidor de desarrollo local pero no cuando lo cargué. Deshacerse de /static y mover todo a un nivel funcionó para mí.

SDK v1.5.2 (Java) en Mac OS X 10.6.8 con Java SE 6 (X predeterminado MacOS)

Cuestiones relacionadas