Статические файлы в (Java) Механизм Приложения, не доступный

Question

Статические файлы в (Java) Механизм Приложения, не доступный

В документации в качестве примера говорится, что просто необходимо поместить файлы в войну / (или подкаталог), и они должны быть доступными от хоста (как долго, поскольку они не JSPs или в СЕТИ-INF). Например, при размещении foo.css в войну / затем, необходимо смочь получить доступ к нему по http://localhost:8080/foo.css. Однако это не работает на меня вообще. НИ ОДИН из моих статических файлов не доступен.

В документах о appengine-web.xml говорится, что можно также конкретно обозначить определенные типы как статичные. Я попробовал это также, и это не имеет никакого значения.

Я пропускаю что-то очевидное?

ОБНОВЛЕНИЕ: Оказывается, что одно из отображений в моем web.xml было немного слишком агрессивно. Следующее было преступником:


    Main
    MainServlet


    Main
    /

Кажется, что это захватывало все, что не было захвачено быть одним из других правил, которые я не понимаю, потому что было не * на конце шаблона URL. Это также, кажется, является непосредственно противоречащим к документации, в которой говорится:

Примечание: Статические файлы, файлы, которые подаются дословно пользователям, таким как изображения, CSS или JavaScript, обрабатываются отдельно от путей, упомянутых в дескрипторе развертывания. Запрос на путь URL, который соответствует пути к файлу в ВОЙНЕ, это рассмотрело статический файл, будет служить файлу, независимо от сервлета и фильтровать отображения в дескрипторе развертывания. Можно исключить файлы из тех, которых обрабатывают статическими файлами с помощью файла appengine-web.xml.

Так, как у меня может быть правило, которое соответствует основе моего домена (например, http://www.example.com/) и все еще позволяет статическим файлам проникать?

13

java google-app-engine web.xml

задан Jeremy Logan 22 June 2009 в 20:29

3 ответа

Другие вопросы по тегам:

java google-app-engine web.xml

Похожие вопросы:

score -2 · Answer 1

При использовании, например, tomcat для обслуживания статических файлов, необходимо указать следующие шаблоны:

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

Может быть, вы могли бы попробовать сделать то же самое?

score 11 · Answer 2

Попробуйте вручную определить статические файлы в appengine-web.xml, например

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

. У меня это работает даже с сервлетами, такими как

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

и

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

См. Статические файлы и файлы ресурсов

score 2 · Answer 3

... Похоже, он схватил все, что не было схвачено, в соответствии с одним из других правил, которое я не понимаю, потому что не было * в конце URL-шаблон. ...

[[К сожалению, термин «сервлет по умолчанию» перегружен, чтобы обозначать разные вещи, что приводит к путанице. Я постараюсь внести ясность.]]

Шаблон URL "/" особенный (Rogue Wave называет это "сопоставлением по умолчанию"). Это определяет «сервлет по умолчанию» приложения, который используется, когда запрос URL не соответствует другим шаблонам (пункт 3 SRV.11.2 и пункт 4 SRV 11.1). Очевидно, «/» обрабатывается так, как если бы вы указали «/ *».

... Это также, кажется, прямо противоречит документации ...

Согласен, я думаю, что в движке приложения есть ошибка, поэтому он не следует документации, которую вы процитировали. Вот моя теория того, что происходит. Поскольку для вашего приложения существует сервлет по умолчанию (в результате определения сервлета для шаблона URL "/"), приложение перестает использовать "default" "default servlet", предоставляемый контейнером для приложений, которые не определяют свой собственный "default servlet" ". «Сервлет по умолчанию» контейнера по умолчанию - это то, что обеспечивает поведение по умолчанию для обслуживания статических файлов.Я думаю, это согласуется с тем, как ведут себя некоторые контейнеры.

Интересно, что произойдет, если вы попытаетесь указать сервлет для шаблона URL, который соответствует статическому файлу. Будет ли он обслуживать файл (как указано в документации) или вызывать сервлет (как указано в этой теории).

... Итак, как я могу иметь правило, которое соответствует базе моего домена (например, http://www.example.com/ ) и по-прежнему позволяет статическим файлам фильтровать ? ...

Если теория верна, решения, предоставленные jacob (адаптированным для движка приложений Google) и zockman, кажутся работоспособными - они сопоставляют статические файлы с "сервлетом по умолчанию" контейнера "по умолчанию".

Единственная другая идея, которая у меня есть, - это написать «сервлет по умолчанию» для вашего приложения, чтобы проверить запрос, чтобы узнать, относится ли он к «/» или нет. Если так, справитесь с этим. Если нет, то (каким-то образом) вызовите "сервлет по умолчанию" контейнера "default" для обработки запроса (который, мы надеемся, кэширует файл). Будем надеяться, что после того, как статический файл был обслужен один раз, кеширование в будущем обойдется без сервлета (ов).

Извините, я не могу уточнить или предоставить код - я не работал с движком приложений Google (пока!).

Ссылка:

JSR-000154 JavaTM Servlet 2.5 Specification (Maintenance Release 2) - http://jcp.org/aboutJava/communityprocess/mrel/jsr154/index2.html - разделы SRV.11.2 и SRV.11.1
http://www2.roguewave.com/support/docs/hydraexpress/3.5.0/html/rwsfservletug/4-3.html#433 - Rogue Wave сервлет по умолчанию
http://tomcat.apache.org/tomcat-4.1-doc/catalina/funcspecs/fs-default.html - сервлет Tomcat по умолчанию