Почему wro4j так собирает css?

 
 
 
Сообщения:283
Обнаружил у себя не корректную работу локально развернутого из сорцов форума: не подгружаются бутстраповские иконки, то есть в визуальном редакторе, например, кнопки без иконок, пустые.

Стал разбираться, оказывается, у меня в main.css ссылки в виде
url("/resources/images/glyphicons-halflings.png")


А вот на самом форуме и на http://qa.jtalks.org/jcommune/ ссылки в "нормальном виде":
url("../../resources/images/glyphicons-halflings.png")


В исходниках в bootstrap.css тоже все нормально. Сделал предположение, что wro4j при сборке режет пути. Только не пойму как. Уже все настройки пересмотрел, документацию перечитал. Может куда не досмотрел? Или это Google closure compiler так себя ведет?

p.s. Вообще wro4j открыл для себя впервые, раньше даже не слышал об этой тулзе.

"Любая техническая система должна быть идиотоустойчивой" (с) один из университетских преподов
 
 
Сообщения:595
BTW, Spring MVC тоже может "переписывать" CSS: http://www.mscharhag.com/spring/resource-versioning-with-spring-mvc
Изменен:21 апр 2016 08:41
 
 
Сообщения:1234
локально он и не нужен
 
 
Сообщения:9774
На самом деле локально он тоже нужен - чтоб проверить как оно будет работать в проде. Поэтому, Mihnayan, если есть желание, будет здорово если заодно и починишь :)
Изменен:21 апр 2016 19:59
 
 
Сообщения:283
Что-то я мозг сломал уже на этой проблеме...

Сделал себе отдельный тестовый проектик для тестирования wro4j. Поведение, однако, от этого не меняется. В итоговом css-файле все url к ресурсам изменяются. С точки зрения пути относительно корня приложения - они правильные. Но в css пути должны указываться относительно места расположения самого css-файла: https://www.w3.org/TR/CSS22/syndata.html#uri. И вот как-то не получается заставить "уважать" этот момент CssUrlRewritingProcessor. Кроме того, появляются сомнения, возможно ли это вообще, глядя на соответствующий метод private String computeNewImageLocation(final String cssUri, final String imageUrl) в классе ImageUrlRewriter:

Интересно, как все-таки ресурсы удачно собрались для javatalks.ru?

"Любая техническая система должна быть идиотоустойчивой" (с) один из университетских преподов
 
 
Сообщения:9774
Хех, ну как-то должно работать :) Правда, javatalks стоит за nginx'ом еще, но это не должно никак влиять на проблему.
 
 
Сообщения:283
Ну я еще поковыряю в этом месте. У народа тоже случаются проблемы:
https://github.com/wro4j/wro4j/issues/718
https://github.com/wro4j/wro4j/issues/748
https://github.com/wro4j/wro4j/issues/784
Причем, оказывается, формирование урлов к ресурсам зависит от операционной системы...

Если я правильно понял автора библиотеки, то он рекомендует использовать оптимизацию ресурсов в рантайме, например, с использованием WroFilter: http://stackoverflow.com/a/32944787. Стоит ли копать в эту сторону? Как-то жалко тратить рантайм на статические ресурсы.

Кстати, а настройки nginx'а можно глянуть, если они не очень секретны конечно?

И, если можно, еще один глупый вопрос: Я так и не понял, что подразумевал masyan под фразой
masyan:
локально он и не нужен

"Любая техническая система должна быть идиотоустойчивой" (с) один из университетских преподов
 
 
Сообщения:1234
Mihnayan
список подлкючаемых ресурсов в html формируется в зависимости от значения свойства мавена isJsComressed (хотя тут и css тоже, возможно стоит переименовать ее). decorator.jsp

Это свойство прописано в главном помнике ,если поставить его false, то ресурсы не будут сжиматся и на страницах будут подцеплятся ресурсы, как они есть (для отладки скриптов локально, в сжатом виде это не удобно делать).
Изменен:27 апр 2016 04:20
 
 
Сообщения:9774
Mihnayan:
Кстати, а настройки nginx'а можно глянуть, если они не очень секретны конечно?
Да там ничего особенного:
    location / {
      proxy_pass http://localhost:8080;
      proxy_set_header Host $http_host;
      proxy_set_header Remote-Addr $http_remote_addr;
      proxy_set_header X-Real-IP $remote_addr;
    }
Mihnayan:
Если я правильно понял автора библиотеки, то он рекомендует использовать оптимизацию ресурсов в рантайме, например, с использованием WroFilter: http://stackoverflow.com/a/32944787. Стоит ли копать в эту сторону? Как-то жалко тратить рантайм на статические ресурсы.
Да, жалковастенько :) Хотя может это один раз происходит, затем все это дело кашеруется.
Изменен:27 апр 2016 05:57
 
 
Сообщения:283
masyan, спасибо! Я, кстати, уже давно обращал внимание в декораторе на эти строки:
<c:choose>
  <c:when test="${mode eq 'true'}">

но стал двигаться в другом направлении, и забыл посмотреть, при каких условиях срабатывает выбор. Наверное, поспешил с вопросом.

В общем, попробую еще поразбираться дальше.

"Любая техническая система должна быть идиотоустойчивой" (с) один из университетских преподов
 
 
Сообщения:283
Спасибо Староверъ за наводку на mvnDebug, с ним я отложил свой бубен в сторону и все пошло гораздо быстрее!

Ответ на главный вопрос темы
Староверъ:
Хех, ну как-то должно работать :)

Это же надо было уйти в глубокий дебаг, чтобы понять, что проблема лежит на повехности! А именно, Windows стал тому причиной (да, собираю я весь проект на Винде).

Все дело в настройке параметра contextFolder в pom.xml:
<contextFolder>${basedir}/src/main/webapp/</contextFolder>


Эта настройка используется в коде для вычисления такого параметра, как aggregatedFolderPath, на основе которого, в свою очередь вычисляется количество каталогов верхнего уровня для ссылки на ресурсы в css. Факт в том, что проблема исчезает, если настройку contextFolder указать в Windows-стиле:
<contextFolder>${basedir}\src\main\webapp\</contextFolder>

то есть, с обратнымы слешами.

Могу описать более подробно, если нужно. Кое-что уже описал на корявом английском в виде issue #1021.

Варианты решения проблемы

1. Можно указать в pom.xml два каталога:
<contextFolder>${basedir}/src/main/webapp/,${basedir}\src\main\webapp\</contextFolder>

Указание нескольких каталогов является документированной возможностью wro4j. В коде же берется первый "успешный" каталог.

2. Можно описать такое поведение в документации jcommune и указать, что если проект собирается на Windows, то изменить правило написания пути для contextFolder.

3. Закинуть баг-репорт автору библиотеки и ждать у моря погоды изменений.

На этом проблема НЕ решена!
Самое интересное, что даже после исправления пути для contextFolder, проблема ушла частично: вместо необходимого
url("../../resources/images/glyphicons-halflings.png")

путь выглядел
url("../resources/images/glyphicons-halflings.png")

То есть, один каталог верхнего уровня все-равно отсутствовал.

Здесь в код лезть не стал, а просто убедился, что это уже пофиксили с версии 1.7.6 (в то время, как jcommune использует версию 1.7.5). Если версию maven-plugin указать начиная с 1.7.6, то все собирается успешно на Windows. Текущий доступный релиз wro4j-maven-plugin - 1.8.0.

"Любая техническая система должна быть идиотоустойчивой" (с) один из университетских преподов
 
 
Сообщения:1234
думаю до 1.7.6 можно обновить и ничего не поломается + путь для винды прописать вторым вариантом, спасибо!
 
 
Сообщения:9774
Супер, отличные результаты, не у каждого выходит так глубоко копнуть :)
Закинешь нам PR? Собсно можно было бы и самому wro4j закинуть тоже фикс их баги.
 
 
Сообщения:1234
Староверъ:
Супер, отличные результаты, не у каждого выходит так глубоко копнуть :)
Закинешь нам PR? Собсно можно было бы и самому wro4j закинуть тоже фикс их баги.


так у них же у самих пофикшено уже
 
Модераторы:Нет
Сейчас эту тему просматривают:Нет