Получение jar-файлов в tomcat / shared / lib для входа в систему, используя конфигурацию вызывающего их веб-приложения

Question

Я пытаюсь обновить наш экземпляр tomcat с 5.5.27 до 6.0.32, и у меня возникают некоторые проблемы с ведением журнала из jars в каталоге shared / lib (я воссоздал этот каталог в tomcat 6).

У нас есть файл jar, который мы создаем как часть нашего процесса сборки с некоторым общим кодом в нем, а в tomcat 5 он находится в shared / lib. Когда мы писали операторы журнала из кода в этом файле jar, они были записаны в файл журнала веб-приложения, вызывающего jar в тот момент. Каждое из наших веб-приложений имеет log4j.properites и log4j.jar в своем каталоге WEB-INF / lib, а в shared / lib также был log4j.jar, но не log4j / properties.

Мы используем log4j и получаем ссылки на журналы следующим образом:

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;    
public class MyClass {
    private final static Log CLASS_LOG = LogFactory.getLog(MyClass.class);
}

Но когда я перемещаю точно такую ​​же конфигурацию наших jar, webapps, log4.properties и log4j.jars в tomcat 6, операторы регистрации из нашего общего jar просто переходят в catalina.log.

Я много читал (включая http://www.mulesoft.com/tomcat-classpath,, а также документацию по загрузке классов и ведению журнала на веб-сайте tomcat), и в основном я не могу понять, как это работало так, как в tomcat 5! (Я не настраивал, это то, что я унаследовал, что до сих пор «просто работало»).

Есть ли у кого-нибудь подобный опыт попыток получить журналы из общих библиотек в файлы журналов веб-приложения? Я думаю, что размещение общего jar-файла в каталоге WEB-INF / lib каждого веб-приложения отсортировало бы это, но тогда у меня было бы много копий одного и того же.

Answer 1

Проверьте tomcat / conf / catalina.properties в tomcat6 / 7.Они устарели как общие пути, так и пути к серверам, явно настроен только общий путь (например, tomcat6 / lib является общим).Вы можете снова включить общий доступ, и я предполагаю, что вы получите опыт, аналогичный tomcat 5.x.

Однако вы сказали, что помещаете logging.properties в WEB-INF / libНе думаю, что это правильно, так как он должен содержать только файлы JAR.Он должен идти в WEB-INF / classes /

Также, на данный момент, прекратите использование регистрации общего достояния.Вместо кода, чтобы slf4j, так как он имеет меньше проблем с tomcat.Кроме того, если вы используете logback вместо log4j, это избавляет даже от необходимости использовать адаптер (например, ваши вызовы slf4j на самом деле являются прямыми вызовами logback).Использует другой конфигурационный файл (но есть онлайн-конвертеры log4j.property).

Answer 2

Я не знаю точно, как настроен загрузчик классов Tomcat. С нашим сервером приложений websphere у нас возникла та же проблема, и нам пришлось перенастроить загрузчик классов, чтобы загрузить «родительский последний».

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

Может быть, в этом дело, и tomcat 5.x был настроен таким образом.

Answer 3

Если вы используете Logback, http://logback.qos.ch/manual/contextSelector.html может делать то, что вы хотите.