ivanraПоясните вкратце как работает класслоадер в томкате? Дык ... .
Иерархический, но без изоляции. Соответственно, "глобальные вещи" выносим в {catalina.base}/lib или даже в системный загрузчик.
Если log4j, то лучше настроить на него самого котяру и "покласть" jar-ник туда, куда удобнее скрипту запуска.

Насколько мне изменяет склероз и беглое чтение документации, в отличии от ДикойМухи (с изоляцией) у вас получится не две конфигурации log4j, а одна, но параметризованная (специальными) свойствами ${engine}, ${host}, ${context} и другими, если они вам понадобятся.

P.S. В своё время я сделал так, что все котяры в кластере использовали собственный номер порта для AJP-коннектора.
Этот номер задавался в скрипте запуска стандартным: а server.xml со товарищи использовали ${префикс.port} для получения разных engine и jvm.route (для индейца во фронте).
Дальше "котовья магия" делала подстановку и после запуска из одного файла получалось много конфигураций, где не пересекалось ничего из нужного: у каждой JVM (приложения в JVM) собственные temp, логи и каталоги для них и т.д. и т.п.
Т.е. весь кластер можно было запустить на одном хосте и он работал без каких-либо проблем.

ivanraТо есть, теоретически, app1 должно писать в log1, app2 - в log2
А фактически на сервере tomcat-7 происходит следующееЯ же говорю - log4j.xml (лучше - xml) должен быть один и предусматривать настройки всех приложений (контекстов), развёрнутых на сервере.
Котяра создаёт категории вида : По умолчанию будет: Т.е. вы дописываете в имеющуюся конфигурацию ещё два аппендера (с разными файлами) и цепляете каждый на свою категорию.

Если я всё правильно помню, то спецсвойства ${engine}, ${host} и ${context} упрощают работу, т.к. котяра сам развёрнёт ${context} в разные значения для разных приложений - просто используем ${context} в имени файла.

ivanraВыяснилось: в classpath сервера лежит еще один log4j, и его трогать нельзя"Ох уж эти сказочки, ох уж эти сказочники".
Аккуратно добавили свой блок. Естественно, договорившись о мирном сосуществовании.