st4j,

А покажите log4j.properties или log4.xml, как Вы настроили логи для пакетов спринга и по какому пути эти файлы попали в вебприложение.

Basil A. SidorovТак вот, в любом раскладе, приложение не может содержать библиотек log4j, т.к. они уже грузится из common-/shared-classpath.

Это не мешает приложениям дублировать библиотеки - класслоадер в томкате устроен, так что всё что лежит в папке WEB-INF/lib имеет высший приоритет чем в расшаренных папках и класслоадер приложения сначала ищет классы в соей папке и только если не нашел нужного класса делигирует загрузку по цепочке common класслоадеру.

tomcat documentation http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
As mentioned above, the web application class loader diverges from the default Java 2 delegation model (in accordance with the recommendations in the Servlet Specification, version 2.4, section 9.7.2 Web Application Classloader). When a request to load a class from the web application's WebappX class loader is processed, this class loader will look in the local repositories first, instead of delegating before looking.

Basil A. SidorovДавайте вы сначала дочитаете котовские мануалы по загрузчикам до деления на "серверный", "разделяемый" и "прикладной", подумаете, в каком порядке они работают
Нет уж только после Вас:
When a web application needs to load a class, the request first comes to the web
application class loader, which is responsible (as described above) for loading the
classes in the web application's WEB-INF/classes and WEB-INF/lib folders.
This class loader first delegates to the System class loader to allow the delegation
hierarchy to locate any core Java classes. If the requested class cannot be found,
then the web application class loader attempts to locate the class within its own
repositories. If the class is still not found, it will delegate to the Common class
loader, or to the Shared class loader if it is installed.

Эх раз ещё раз, ещё много-много-много раз.

Basil A. SidorovТак вот, в любом раскладе, приложение не может содержать библиотек log4j, т.к. они уже грузится из common-/shared-classpath.
То что log4j может грузится из common-/shared-classpath, никак не мешает мне иметь для каждого приложения свою версию библиотеки log4j.
Допустим сценарий:
1. Задеплоено приложение "A" без библиотеки log4j в WEB-INF/lib, оно рассчитывает подхватить её из общих либ, допустим так и происходит, дело дошло до shared заррузчика(если он настроен) и он загрузил классы log4j для "A".
2. Теперь деплоется приложение "B", которое содержит в WEB-INF/lib библиотеку log4j, ну допустим версия в shared не устраивает и "B" нужен более новый log4j а может и наоборот более старый. Так вот приложение "B" получит свою версию log4j из папки WEB-INF/lib несмотря то что по требованию приложения "A" shared загрузчик уже подгрузил классы из другой либы в память, то есть разные версии классов log4j будут прекрасно сосуществовать в памяти.

Поэтому ещё раз обновите в памяти иерархию класслоадеров в томкат, Вам это явно не помешает.