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

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

13 голосов
/ 22 июня 2009

Пример документации говорит, что вам просто нужно поместить ваши файлы в war / (или в подкаталог), и они должны быть доступны с хоста (если они не являются JSP или в WEB-). INF). Например, если вы разместите файл foo.css на войне /, тогда вы сможете получить к нему доступ в 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/) и все же позволяет фильтровать статические файлы?

Ответы [ 4 ]

11 голосов
/ 25 марта 2010

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

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

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

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

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

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

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

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

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

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

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

Ref:

1 голос
/ 14 августа 2011

Я понимаю, что это действительно старый вопрос, но я столкнулся с той же проблемой. Я поместил свои 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 по умолчанию)

0 голосов
/ 17 марта 2010

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

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

...