applicationContext не находит controllerы для контекста сервлета

У меня есть веб-приложение Spring с приложением applicationContext.xml и конфигурацией dispatcher-servlet.xml. Я определил в applicationContext.xml, но когда я запустил приложение, controllerы не будут найдены, если я также не добавлю в dispatcher-servlet.xml. Я использую один и тот же базовый пакет для обоих, так что это не проблема.

Я смущен, потому что я думал, что applicationContext.xml является родителем dispatcher-servlet.xml. Не помещал бы в applicationContext.xml?

web.xml

    contextConfigLocation classpath:applicationContext.xml   org.springframework.web.context.ContextLoaderListener   dispatcher org.springframework.web.servlet.DispatcherServlet  contextConfigLocation /WEB-INF/dispatcher-servlet.xml  1   dispatcher /   к    contextConfigLocation classpath:applicationContext.xml   org.springframework.web.context.ContextLoaderListener   dispatcher org.springframework.web.servlet.DispatcherServlet  contextConfigLocation /WEB-INF/dispatcher-servlet.xml  1   dispatcher /   

EDIT: Я также использую mvc: annotation-driven в dispatcher-servlet.xml, который должен забрать controllerы (я думал?).

EDIT 2: Вот файлы конфигурации. Я удалил набор параметров Spring Security и OAuth из applicationContext.xml (по соображениям безопасности и, вероятно, они не имеют отношения к делу).

applicationContext.xml

      

диспетчер-servlet.xml

                      

EDIT 3: Хорошо, это интересно. Мои сервисы и classы dao находятся в другом проекте (JAR), который я ссылаюсь на веб-проект. Я использую java-config и ссылаюсь на него из applicationContext.xml:

  

Таким образом, это означает, что в моем веб-проекте (где находится applicationContext.xml) есть только annotations Controller. В ретроспективе удаление контекста: компонент-сканирование из моего applicationContext.xml не должно иметь никакого влияния, так как нет комментариев, кроме @Controller (FIX to EDIT: есть некоторые @Autowired annotations). Но когда я удаляю контекст: компонент-сканирование из applicationContext.xml, он говорит, что controllerы (найденные из сканирования сервлетов диспетчера) не могут найти мои classы обслуживания. Должна ли быть достаточной ссылка на ServiceConfig? Вот class ServicesConfig для ссылок – у него есть собственное сканирование компонентов для Сервисов, которые представляют собой другой пакет, из которого сканировался applicationContext.xml.

 @Configuration @ComponentScan({ "some.other.package", "another.package" }) @ImportResource({ "classpath:commonBeans.xml" }) @PropertySource({ "classpath:services.properties", "classpath:misc.properties" }) public class ServicesConfig { // Bean definitions // } 

РЕШЕНИЕ:

Когда я удалил контекст: компонент-сканирование из моего корневого контекста, controllerы не собирали факсимированные сервисные компоненты. Это связано с тем, что корневой контекст ссылается на мои сервисы java-based config Bean, но у меня не было настройки корневого контекста для сканирования компонентов. Следовательно, когда я добавляю компонентное сканирование в корневой контекст (applicationContext.xml), все работает. Вот что у меня есть сейчас:

applicationContext.xml:

   

диспетчер-servlet.xml:

  

У меня есть настройка веб-контекста для настройки controllerа, Autowired и любых других аннотаций в пакете controllerа. Я не уверен, что это лучшая практика или нет.

Вы правы – есть два разных контекста приложения: контекст корневого приложения, загруженный ContextLoaderListener (в точке, когда ServletContext получает инициализацию), и веб-контекст (загруженный DispatcherServlet), корневой контекст приложения является родителем веб-сайта контекст.

Теперь, поскольку это два разных контекста приложения, они действуют по-разному – если вы определяете component-scan для своих сервисов в контексте приложения, тогда все компоненты для сервисов создаются здесь.

Когда ваш сервлет-диспетчер загрузится, он начнет создавать веб-контекст, в какой-то момент (управляемый он создаст сопоставление для методов вашего uri-обработчика, он получит список компонентов в приложении контекст (который будет контекстом веб-приложения, а не контекстом корневого приложения), и поскольку вы не определили component-scan связанные с ним компоненты, связанные с controllerом, не будут найдены, и сопоставления не будут созданы, вот почему вы также определить компонент-сканирование в контексте сервлетов диспетчера.

Хорошей практикой является исключение связанных с controllerом компонентов в контексте корневого приложения:

    

и только связанный с controllerом контекст веб-приложения:

    

В наших приложениях мы определяем в dispatcher-servlet.xml

Я считаю, что именно там он должен быть, а не в applicationContext.xml

Этот раздел весенней документации должен содержать дополнительную информацию:

http://static.springsource.org/spring/docs/current/spring-framework-reference/html/mvc.html

Как видно из одной из диаграмм в разделе 16.2, диспетчер-сервлет сидит над applicationContext в иерархии контекста.

У меня была та же проблема, и после сравнения моего кода web.xml с этим уроком я изменил его, и он сработал. вот мой web.xml :

   contextConfigLocation classpath:spring/business-config.xml   org.springframework.web.context.ContextLoaderListener   mvc-dispatcher org.springframework.web.servlet.DispatcherServlet   mvc-dispatcher /  

context-param и listener – это то, что я пропустил.

Надеюсь, это поможет вам.

  • создать два метода для одного и того же шаблона url с разными аргументами
  • Как обслуживать файлы .html с помощью Spring
  • Включить сериализацию HAL в Spring Boot для пользовательского метода controllerа
  • Как показать все controllerы и отображения в представлении
  • Spring CORS Нет заголовка «Access-Control-Allow-Origin»
  • Spring Boot Multiple Datasource
  • Может ли Spring Security использовать @PreAuthorize для методов весенних controllerов?
  • В чем разница между ApplicationContext и WebApplicationContext в Spring MVC?
  • Нет найденного WebApplicationContext: зарегистрирован ли ContextLoaderListener?
  • Spring 4 RestController JSON: характеристики недопустимы в соответствии с заголовками запроса «принять»
  • Не найдено сопоставления для HTTP-запроса с URI
  • Interesting Posts
    Давайте будем гением компьютера.