#java #eclipse #tomcat #helios
#java #eclipse #tomcat #helios
Вопрос:
Недавно я перенес веб-приложение, которое я разрабатывал, на новую машину под управлением 64-разрядного Eclipse Helios (Service Release 2), и я использую плагин Maven M2Eclipse.
Я развернул локальную установку tomcat через Eclipse, и все в порядке (более или менее), но я хочу выбрать опцию «Обслуживать модули без публикации», но когда я выбираю эту опцию, я получаю ошибки:
log4j:ERROR Could not read configuration file from URL [file:/C:/butterfly/svn/trunk/micro/src/main/webapp/WEB-INF/classes/log4j.properties].
java.io.FileNotFoundException: C:butterflysvntrunkmicrosrcmainwebappWEB-INFclasseslog4j.properties (The system cannot find the file specified)
Файла log4j.properties там нет, как и в моих исходных каталогах в src / main /resources — при сборке он затем копируется в target/WEB-INF/classes /..
Похоже, что Eclipse смешивает ожидаемый целевой каталог с каталогом src, поэтому не находит его.
Я не уверен, происходит ли это только для файла свойств или та же проблема возникнет при поиске всех встроенных ресурсов.
Я видел эти проблемы:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=318449
http://www.eclipse.org/forums/index.php?t=msgamp;goto=661045amp;S=25bafd85b11e042c169ecf1752bfa479
но они, похоже, немного отличаются или уже исправлены (мой Helios — это новая загрузка с прошлых выходных)
Кто-нибудь сталкивался с этим или знает, как решить?
Комментарии:
1. Какую версию Tomcat вы используете? Я заметил, что это сломалось в моей версии Eclipse, когда я перешел на Tomcat 7, что, похоже, подтверждается eclipse.org/forums/… . По-видимому, это было не исправлено в Helios, как указывают последние несколько комментариев. Таким образом, обходным путем, по-видимому, является возврат к Tomcat 6…
Ответ №1:
Отсюда: «Опция Подачи модулей без публикации выполняет то, что она говорит. Веб-контент будет обслуживаться непосредственно из папки «WebContent» динамического веб-проекта. Настраиваемый контекст используется для того, чтобы сделать зависимости проекта доступными в загрузчике классов веб-приложения «. Я бы ожидал, что eclipse будет эмулировать обслуживание каждого файла класса / ресурса (включая log4j.properties) из WEB-INF / classes после сборки проекта. В качестве обходного пути, как насчет создания папки «классы» внутри WebContent, скопируйте файл log4j.properties сюда и посмотрите, будет ли загрузчик классов доволен?
Комментарии:
1. Спасибо за ответ — к сожалению, ни один из скомпилированных классов не находится в папке веб-содержимого (поскольку соглашение maven строится по /target / .. и все исходные папки /src /.. Кроме того, до перехода на Helios это отлично работало в Galileo, и я работал с несколькими проектами maven, выбрав «обслуживать модули без публикации», и eclipse запустил их из каталога maven / target / .. — так вы знаете, это просто сломано / удалено или мне нужен дополнительный шаг настройки?
2. @rinds Я почти уверен, что это что-то специфичное для вашего проекта, что не очень хорошо сочетается с этой функцией пользовательского загрузчика классов. Вам не потребуется никакого дополнительного шага настройки. Но, как я уже говорил ранее, попробуйте создать папку classes внутри WEB-INF и скопировать log4j.properties туда.
3. @Anthony, я создал папку classes внутри src / main / webapp /WEB-INF и скопировал файл log4j, затем он пожаловался на persistence.xml , поэтому я скопировал это заново — тогда это работает. Это очень странно, поскольку в той же папке src (src / main / resources), что и log4j, есть другие файлы конфигурации Spring XML, но они корректно использовались из целевой выходной папки.. есть идеи?
4. @rinds. Eclipse использует пользовательский загрузчик классов, который выполняет трюк «Обслуживать модули без публикации». Многие фреймворки используют свои собственные загрузчики классов. Обеспечить их хорошую работу (даже для таких простых вещей, как получение некоторого ресурса classpath) — непростая задача. Поскольку у вас все готово, я бы попытался открыть ошибку при голосовании и посмотреть, сможете ли вы получить достаточный кворум. Кроме того, есть другие способы добиться чего-то подобного. Например, вы можете создать пользовательский context.xml в соответствии с вашими потребностями.
5. И поскольку вы используете maven, существуют плагины, которые могут выполнять развертывание на месте для Tomcat. Есть ли какая-либо причина, по которой вы не можете позволить maven управлять развертыванием?