Взялся за spring security. Хочу прикрутить авторизацию.
web.xml

security-applicationContext.xml


При запуске приложения пишет 


Погуглил немного по эксепшену, встретил предложение скопировать spring-security-core в либы томката, сдалал, получаем

Ага, не хватает какого-то класса, а именно NamespaceHandlerSupport. Который лежит в spring.jar, копируем и его туда же. Получаем:


Короче труба. Что это такое может быть?

убери в


auto-config="true"

По SecurityNamespaceHandler тоже что-то было, когда прикручивал, но счас под рукой проекта нету, пока ничего сказать не могу... Завтра отвечу

Спасибо, буду ждать 

ты знаешь, по-моему достаточно все-таки убрать 
auto-config="true"
и добавь вот это:

К сожалению не помогло. Ошибка та же.

Тут либо возвращаться к самому началу, либо курить дальше.
Если возвращаться к первому, выкидываем из либ томката spring-security  и spring. 
Нахожу подобную тему http://forum.springsource.org/showthread.php?t=71171, насколько я понял классы спринга грузились другим класслоадером, из-за того, что джарники лежали не в класспасе. На данный момент спринговые джары лежат только в либах приложения. А может я вообще не верно понял?

У меня JBOSS. И эти либы лежат в WEB-INF/lib моего war'a

вот такие там Spring-либы:
aspectjrt-1.5.4.jar
aspectjweaver.jar
spring-security-acl-2.0.4.jar
spring-security-core-2.0.4.jar
spring-security-core-tiger-2.0.4.jar
spring-security-taglibs-2.0.4.jar
spring-web-2.0.8.jar
spring-webmvc-2.0.8.jar
spring.jar
standard-1.1.2.jar
jstl-1.1.2.jar

еще тут же лежат коммоновские либы:
commons-beanutils.jar
commons-collections.jar
commons-digester.jar
commons-logging.jar

Точно помню, что была такая же проблемка, как и у тебя, но она возникала на том примере, что идет в дистрибутиве spring-security-2.0.4

antlr.jar
asm.jar
cglib.jar
commons-collections.jar
commons-logging.jar
commons-logging_1.jar
dom4j.jar
ejb3-persistence.jar
hibernate.jar
hibernate-annotations.jar
jcaptcha-1.0-all.jar
jstl-1.2.jar
jta-1.1.jar
mysql-connector-java-5.1.5-bin.jar
spring.jar
spring-security-acl-2.0.4.jar
spring-security-core-2.0.4.jar
spring-security-core-tiger-2.0.4.jar
spring-security-taglibs-2.0.4.jar
spring-webmvc.jar
standard.jar
urlrewrite-2.6.0.jar

Вот что у меня лежит в либах приложения, думаю тут всего хватает.



И какое решение было найдено?

у тебя в списке нету
commons-beanutils.jar
commons-digester.jar
  

помню, что забил на это дело и начал писать свое приложение по тем примерам: свою форму логина, свои паттерны сукьюрити, свои фильтры.
Ну и работает счас, логинится заказчик через LDAP со своими ролями. И даже сессия рубается лишняя...

Проблема решена.
Оказалось, что либы не деплоились вместе с приложением на сервер. Настроил задеплоил и все окей, теперь все либы лежат вместе с приложением.

Добавлено через 2 минуты и 49 секунд
MisterCleric, спасибо за помощь

А за что они отвечают?

не совсем понял, что ты этим хотел сказать 

Ну это ж уже не вопросы к сукьюрити...



вот мой security-context, а вось да что-то поможет:

Столкнулся вчера с аналогичной проблемой в рамках Hosted Server'а GWT, поэтому поделюсь опытом.

Убил несколько часов на поиски проблемы в логах, пока не решил изменить подход к делу и отдебажить сам спринг.
Для этого (если у вас eclipse), в Build Path проекта для библиотеки spring.jar (или для spring-web.jar, если спринг подключен помодульно) назначаем папку с исходниками. Открываем org.springframework.web.context.ContextLoaderListener и ставим бряку в contextInitialized() на this.contextLoader.initWebApplicationContext(event.getServletContext()); 

Запускаем проект в дебаг-режиме, дожидаемся брейкпоинта и после него шагаем, пока не наткнемся на Exception. Остается в окне Variables посмотреть значение cause.

PS. Вроде бы можно добиться подобного настроив log4j, но мне не удалось.

PPS. В моем случае проблема оказалось совсем смешной - недоставало библиотек aopalliance.jar и aspectjrt.jar

А попробуй уровень логгирования для Spring поставить DEBUG: