2013-12-17 3 views
2

Спрошу мои вопросы, а потом вдаваться в подробности:GWT, Tomcat, 2 модуля, JRebel: DevMode ищет nocache.js в неправильном месте и показывает 404 не найден

  1. Какую функцию hosted.html файлов играет в DevMode и почему его запрашивают со страницы, например hosted.html?<module-name>, и как я могу контролировать/настраивать то, что возвращается этим запросом? Если кто-нибудь ответит на этот вопрос, я отвечу & с ответом, так как я уже нашел ответы на 2-й и 3-й вопросы сам, и они, похоже, не связаны с моей проблемой.

  2. Есть ли способы запуска обновления кэша GWT вместо обычного браузера Ctrl-F5? В каждом модуле я видел сгенерированный во время компиляции файл clear.cache.gif - имеет ли он какое-либо отношение к кеш-памяти GWT? уже ответил сам, и не кажется, что большую помощь в этой ситуации

  3. ли я правильно указано DevMode сек -war пути (смотри ниже)? Должен ли я указывать абсолютный путь к папке src/main/webapp? уже ответил сам и, похоже, не очень поможет в этой ситуации

  4. В чем проблема с моей установкой и почему у меня возникла проблема, описанная ниже? (необязательно, чтобы ответить, но если правильно ответили - я upvote & принять ответ сразу :))

EDIT - подробности, относящиеся к 1-й вопрос

Итак, есть 2 GWT модули: login и dashboard в моем webapp. Проблема заключается в том, что в DevMode страницы login.html, содержащая только login модуля всегда нагрузки обычно, делая после запроса

GET http://localhost:8080/login/hosted.html?login    200 OK 

который возвращает стандартную hosted.html страницы, которая генерируется GWT компилятором и поместить в папку для каждого модуля.

Но somewhy dashboard.html страница, содержащая только dashboard модуль не загружается нормально сделать следующий запрос:

GET http://localhost:8080/dashboard/hosted.html?dashboard  304 Not Modified 

Cache-Control:private 
Date:Tue, 17 Dec 2013 13:07:40 GMT 
ETag:W/"11781-1367504122000" 
Expires:Thu, 01 Jan 1970 03:00:00 EET 
Last-Modified:Thu, 02 May 2013 14:15:22 GMT 
Server:Apache-Coyote/1.1 

Что удивительно возвращает login.html страница как результат, а не стандартный hosted.html файл, который я хотел бы ожидать. Обратите внимание, что это происходило довольно редко в течение последних полугода и решалось нажатием Ctrl-F5 несколько раз. Но со вчерашнего дня это происходит всегда.

Продолжить поиск, кто или что делает запрос до hosted.html?dashboard и кто отвечает на него с таким странным откликом.

EDIT # 2 - детали, относящиеся к 1-й вопрос Выяснилось, что проблема на стороне сервера - somewhy ответ на второй запрос (о которых говорилось выше) имеет код состояния 304 Not Modified. При отладке кода Catalina выяснилось, что проблема связана с классом org.zeroturnaround.javarebel.integration.fileservlet.FileServlet, который в конце служит файлу. Этот класс от JRebel (версия 5.2.2), который запускается с Tomcat с использованием опции -javaagent. Если я удалю опцию -javaagent и запустил Tomcat без JRebel, все будет нормально работать, и файл исправен. Постарайтесь углубиться и выяснить проблему в классе JRebel.

EDIT # 3 - детали, относящиеся к 1-й вопрос

После обновления до JRebel-5.4.2 ошибка по-прежнему сохраняется. Создана тема на форуме Zeroturnaround: http://zeroturnaround.com/forums/topic/gwt-devmode-tomcat-7-0-39-possible-fileservlet-bug/

Подробное описание моей проблемы (ничего очень интересно - просто детали :)):

У меня возникли проблемы с Devmode из веб-приложение работает 2 модуля под названием login и dashboard. Webapp развертывается локально стандартной установки Tomcat и имеет структуру каталогов, как следующие:

<tomcat_folder>/webapps/ROOT/login.html 
<tomcat_folder>/webapps/ROOT/login/ 
<tomcat_folder>/webapps/ROOT/login/<single gwt.rpc file> 
<tomcat_folder>/webapps/ROOT/login/<multiple .cache.html files> 
<tomcat_folder>/webapps/ROOT/login/gwt/<standard files> 
<tomcat_folder>/webapps/ROOT/login/clear.cache.gif 
<tomcat_folder>/webapps/ROOT/login/login.nocache.js 
<tomcat_folder>/webapps/ROOT/login/hosted.html 

<tomcat_folder>/webapps/ROOT/dashboard.html 
<tomcat_folder>/webapps/ROOT/dashboard/ 
<tomcat_folder>/webapps/ROOT/dashboard/<two .gwt.rpc files> 
<tomcat_folder>/webapps/ROOT/dashboard/<multiple .cache.html, .cache.png, etc files> 
<tomcat_folder>/webapps/ROOT/dashboard/gwt/<standard files> 
<tomcat_folder>/webapps/ROOT/dashboard/clear.cache.gif 
<tomcat_folder>/webapps/ROOT/dashboard/dashboard.nocache.js 
<tomcat_folder>/webapps/ROOT/dashboard/hosted.html 
<tomcat_folder>/webapps/ROOT/dashboard/<other css and image resources used by page> 

<tomcat_folder>/webapps/ROOT/<other files of webapp> 

Теперь, login.html содержит ссылку на login.nocache.js файл, как в следующем: файл

<script src="login/login.nocache.js" type="text/javascript" language="javascript"></script> 

dashboard.html содержит ссылки на dashboard.nocache.js соответственно :

<script src="dashboard/dashboard.nocache.js" type="text/javascript" language="javascript"></script> 

Я запускаю DevMode от Eclipse со следующими параметрами:

-remoteUI "${gwt_remote_ui_server_port}:${unique_id}" 
-startupUrl http://localhost:8080/login.html -logLevel INFO 
-noserver -war <absolute-path-to-tomcat-folder>/webapps/ROOT 
-codeServerPort 9997 
org.yura.cases.DashboardModule org.yura.cases.LoginModule 

Сейчас я работаю с такой установкой на уже пол года, и сейчас все работает нормально, то есть она работает безупречно, не в DevMode и, скажем, 95% времени Я успешно работал с DevMode - отлаживая код, меняя его в Eclipse и т. Д.

Но, проблема в том (и в прошлом), что время от времени, когда я открываю

http://localhost:8080/dashboard.html?gwt.codesvr=127.0.0.1:9997 

страница пуста, и я вижу следующее сообщение об ошибке в браузерах консоли:

GET http://localhost:8080/dashboard/login/login.nocache.js/ 404 (Not Found) hosted.html:10 

Когда я иду в hosted.html:10 файл, который загружается во время загрузки страницы я вижу, что этот файл будет загружен из следующего URL:

http://localhost:8080/dashboard/hosted.html?dashboard 

и возвращаемый HTML файл действительно содержит неправильный путь к login.nocache.js:

<script src="login/login.nocache.js" type="text/javascript" language="javascript"></script> 

(путь является неправильным, потому что login/login.nocache.js' is relative path and it resolves to панель/Логин/login.nocache.js`)

До сегодняшнего дня, я обошел эту проблему просто удерживая Ctrl-F5 в течение нескольких секунд, чтобы перезагрузить страницу и очистить кеш браузера и, в конечном итоге, загрузить страницу в DevMode. Однако сегодня, независимо от того, как долго я нажимаю Ctrl-F5, ошибка сохраняется. Вот почему я решил окончательно решить эту проблему раз и навсегда.

Заранее благодарим за любую помощь!

ответ

1

Нашел ответы на мой второй и третий вопрос, хотя они, похоже, не очень помогают моей проблеме. В любом случае, поделитесь ими здесь:

Вопрос 2. Существуют ли способы запуска обновления кеша GWT вместо простого браузера Ctrl-F5? В каждом модуле, который я видел, генерируется во время компиляции. Файл clear.cache.gif - имеет ли он какое-либо отношение к кеш-памяти GWT?

По http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html#launching_a_browser:

Вам не нужно перезапустить режим развития после изменения исходного кода. Вместо этого, когда режим разработки все еще запущен, отредактируйте клиентский код или ресурсы, сохраните изменения и обновите страницу в своем браузере.

И согласно GWT project directory creation by hand:

clear.cache.gif является 1x1 кэшируемым изображение, используемое, чтобы заполнитель для тега. См http://code.google.com/p/google-web-toolkit/wiki/ImageBundleDesign («Clipping конструктора для изображения»)

Так получается, что в моем случае, нажав F5 или Ctrl-F5 полностью следует сделать трюк, и нет никаких других средств «освежающего» GWT кэша по крайней мере, хорошо заявленные общественности.

Вопрос 3. Правильно ли я указал путь DevModes -war (см. Ниже)? Должен ли я указывать абсолютный путь к папке src/main/webapp?

Да, согласно Using my own server in development mode instead of GWT's built-in Jetty instance учебник, я указал -war вариант правильно.

EDIT - нашел ответ на 4 вопрос (решение моей проблемы) Итак, оказалось, что ошибка была в org.zeroturnaround.javarebel.integration.fileservlet.FileServlet классе, который был неправильно обработки ETag заголовка в редких случаях. Вот почему он обслуживал контент login.html, который ранее был возвращен Tomcat в результате не аутентифицированного доступа к защищенному ресурсу /dashboard/hosted.html?dashboard (странное, но стандартное поведение Tomcat). Исправление ошибки в JRebel должен появиться в сегодняшней ночной сборки, и я 99% уверен, что он будет работать :)

Для получения дополнительной информации, пожалуйста, обратитесь к этой дискуссии: http://zeroturnaround.com/forums/topic/gwt-devmode-tomcat-7-0-39-possible-fileservlet-bug/#post-39379

действительно надеюсь, что это помогает кто-то еще :)

 Смежные вопросы

  • Нет связанных вопросов^_^