@ RichW прав, утверждая, что размещение библиотек Spring в общем загрузчике классов Tomcat - плохая практика. И есть большая вероятность, что это не сработает.
Java использует иерархию загрузчика классов ). Когда запрашивается загрузка класса, загрузчик классов будет рекурсивно запрашивать класс у своего родительского загрузчика классов, прежде чем пытаться загрузить класс, используя собственный путь к классу. Этот процесс продолжается до корневого загрузчика классов (известного как загрузчик классов начальной загрузки). Таким образом, классы, на которые ссылается родительский загрузчик классов, всегда получают приоритет над классами, на которые ссылаются загрузчики классов, ниже по иерархии.
Важно отметить, что в этом процессе классы никогда не загружаются из дочернего загрузчика классов. Поэтому любые классы, требуемые Spring, также должны быть загружены в общий загрузчик классов - включая asm, log4j, commons-logging и cglib (все от которых зависит Spring). Это приведет к целому ряду проблем: в частности, регистрация общего достояния в общем пути к классам - это целый мир боли
Если вам действительно удастся запустить Tomcat, у вас возникнут проблемы с утечками памяти при утилизации приложений. В tomcat приложения выгружаются с использованием обычной сборки мусора, поэтому, если что-то содержит ссылку на класс внутри приложения, которое впоследствии было перезапущено, это приложение не получит сборку мусора. Среды Spring и logging являются основными кандидатами для хранения ссылок на классы, поэтому вы, вероятно, будете страдать от ошибок OOM после нескольких перезапусков приложения.
Единственный способ сделать это безопасно - рассмотреть возможность использования полноценного сервера приложений (такого как JBoss AS) и развертывания приложения в качестве EAR.