Статические файлы в (Java) App Engine недоступны

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

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

Я пропустил что-то очевидное?

UPDATE: Оказывается, одно из отображений в моем web.xml было слишком агрессивным. Следующим был виновник:

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

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

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

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

ОТВЕТЫ

Ответ 1

Попробуйте вручную определить статические файлы в 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>

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

Ref:

Ответ 3

Я понимаю, что это действительно старый вопрос, но я столкнулся с той же проблемой. Я поместил css/*.css, js/*.css и favicon.ico в /war/static/ и использовал директиву public_root в своем appengine-web.xml, чтобы указать на /static. Это отлично работало на моем локальном сервере-разработчике, но не при загрузке приложения. Избавиться от /static и перемещать все до уровня, который работал у меня.

SDK v1.5.2 (Java) на Mac OSX 10.6.8 с Java SE 6 (MacOS X по умолчанию)

Ответ 4

При использовании, например, 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>

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