Я изучаю Spring Framework, который используется в моем проекте. Я нашел запись ContextLoaderListener в моем файле web.xml . Но не могли бы понять, как именно это помогает разработчику?
В официальной документации ContextLoaderListener говорится, что он должен запускать WebApplicationContext . Относительно WebApplicationContext JavaDocs говорят:
Интерфейс для предоставления конфигурации для веб-приложения.
Но я не могу понять, чего я добиваюсь с помощью ContextLoaderListener, который внутренне инициализирует WebApplicationContext ?
Насколько я понимаю , ContextLoaderListener читает конфигурационный файл Spring (со значением, заданным для contextConfigLocation в web.xml ), анализирует его и загружает bean-компонент singleton, определенный в этом конфигурационном файле. Точно так же, когда мы хотим загрузить прототип bean , мы будем использовать тот же контекст веб-приложения, чтобы загрузить его. Таким образом, мы инициализируем веб-приложение с помощью ContextLoaderListener, чтобы заранее прочитать / проанализировать / проверить файл конфигурации, и всякий раз, когда мы хотим внедрить зависимость, мы можем сразу сделать это без каких-либо задержек. Это понимание правильно?
источник
Ответы:
Ваше понимание верно. Там
ApplicationContext
, где живут ваши весенние бобы. ЦельContextLoaderListener
состоит из двух частей :привязать жизненный цикл
ApplicationContext
к жизненному циклуServletContext
иавтоматизировать создание
ApplicationContext
, так что вам не нужно писать явный код для его создания - это удобная функция.Еще одна удобная вещь о
ContextLoaderListener
том , что он создаетWebApplicationContext
иWebApplicationContext
обеспечивает доступ кServletContext
черезServletContextAware
фасолью иgetServletContext
метод.источник
WebApplicationContext
. В противном случае это должно было бы быть создано вручную.ContextLoaderListener
реализовать метод уничтожения , чтобы уничтожить все бобы , когда веб - контейнер закрывается вниз?contextDestroyed
называется. Смотрите документацию по API.web.xml
. В моем XML-файле есть два слушателяContextLoaderListener
иDispatcherServlet
. Итак, я думаю, что нет необходимости в обоих, безопасно ли удалить,ContextLoaderListener
почему я спрашиваю, потому что приложение живет 7-8 месяцев. web.xml здесь для вашей справки.ContextLoaderListener
является необязательным . Просто чтобы подчеркнуть: вы можете загрузить приложение Spring без какой-либо настройкиContextLoaderListener
, просто базовый минимумweb.xml
сDispatcherServlet
.Вот как это будет выглядеть:
web.xml
Создайте файл с именем
dispatcher-servlet.xml
и сохраните его вWEB-INF
. Поскольку мы упоминалиindex.jsp
в списке приветствий, добавьте этот файл вWEB-INF
.диспетчер-servlet.xml
В
dispatcher-servlet.xml
определять бобы:источник
Для простого приложения Spring вам не нужно определять
ContextLoaderListener
в своемweb.xml
; Вы можете просто поместить все свои файлы конфигурации Spring в<servlet>
:Для более сложного приложения Spring, где у вас есть несколько
DispatcherServlet
определенных, у вас могут быть общие файлы конфигурации Spring, которые совместно используются всемиDispatcherServlet
определенными вContextLoaderListener
:Просто имейте в виду,
ContextLoaderListener
выполняет фактическую работу инициализации для контекста корневого приложения.Я обнаружил, что эта статья очень помогает: Spring MVC - контекст приложения против контекста веб-приложения
источник
Блог " Цель ContextLoaderListener - Spring MVC " дает очень хорошее объяснение.
Согласно этому, контексты приложения являются иерархическими и, следовательно, контекст DispatcherSerlvet становится потомком контекста ContextLoaderListener. Благодаря этому технология, используемая на уровне контроллера (Struts или Spring MVC), может не зависеть от корневого контекста, созданного ContextLoaderListener.
источник
Если вы хотите поместить свой файл сервлета в свое пользовательское местоположение или с пользовательским именем, а не в соглашение о присвоении имен
[servletname]-servlet.xml
и путь по умолчаниюWeb-INF/
, тогда вы можете использоватьContextLoaderListener
.источник
ContextLoaderListner - это прослушиватель сервлетов, который загружает все различные файлы конфигурации (конфигурация уровня обслуживания, конфигурация уровня персистентности и т. Д.) В единый контекст приложения Spring.
Это помогает разделить конфигурации Spring на несколько файлов XML.
Как только файлы контекста загружены, Spring создает объект WebApplicationContext на основе определения компонента и сохраняет его в ServletContext вашего веб-приложения.
источник
Этот слушатель Bootstrap предназначен для запуска и завершения работы корневого WebApplicationContext в Spring. Поскольку веб-приложение может иметь несколько сервлетов-диспетчеров, и каждый из них имеет свой собственный контекст приложения, содержащий контроллеры, преобразователь представления, сопоставления обработчиков и т. Д. Но вы можете захотеть иметь служебные компоненты, компоненты DAO в контексте корневого приложения и использовать их во всех дочерних контекстах приложения ( контекст приложения, созданный диспетчерскими сервлетами).
Второе использование этого слушателя, когда вы хотите использовать Spring Security.
источник
Коренные и дочерние контексты Прежде чем читать дальше, пожалуйста, поймите, что -
Spring может иметь несколько контекстов одновременно. Одним из них будет корневой контекст, а все остальные контексты будут дочерними контекстами.
Все дочерние контексты могут получить доступ к bean-компонентам, определенным в корневом контексте; но обратное не верно. Корневой контекст не может получить доступ к дочерним контекстам bean.
ApplicationContext:
applicationContext.xml - это корневая контекстная конфигурация для каждого веб-приложения. Spring загружает файл applicationContext.xml и создает ApplicationContext для всего приложения. В каждом веб-приложении будет только один контекст приложения. Если вы явно не объявляете имя файла конфигурации контекста в файле web.xml с помощью параметра contextConfigLocation, Spring выполнит поиск applicationContext.xml в папке WEB-INF и сгенерирует исключение FileNotFoundException, если не удалось найти этот файл.
ContextLoaderListener Выполняет фактическую работу инициализации для контекста корневого приложения. Считывает контекстный параметр «contextConfigLocation» и передает его значение экземпляру контекста, анализируя его в потенциально множественных файловых путях, которые могут быть разделены любым количеством запятых и пробелов, например «WEB-INF / applicationContext1.xml, WEB-INF / applicationContext2.xml». ContextLoaderListener является необязательным. Просто чтобы подчеркнуть: вы можете загрузить приложение Spring без какой-либо настройки ContextLoaderListener, просто базовый минимум web.xml с DispatcherServlet.
DispatcherServlet DispatcherServlet по сути является сервлетом (он расширяет HttpServlet), основной целью которого является обработка входящих веб-запросов, соответствующих настроенному шаблону URL. Он принимает входящий URI и находит правильную комбинацию контроллера и вида. Так что это передний контроллер.
Когда вы определяете DispatcherServlet в весенней конфигурации, вы предоставляете XML-файл с записями классов контроллеров, отображений представлений и т. Д., Используя атрибут contextConfigLocation.
WebApplicationContext Помимо ApplicationContext, в одном веб-приложении может быть несколько WebApplicationContext. Проще говоря, каждый DispatcherServlet связан с одним WebApplicationContext. Файл xxx-servlet.xml специфичен для DispatcherServlet, и веб-приложение может иметь более одного DispatcherServlet, настроенного для обработки запросов. В таких сценариях для каждого DispatcherServlet будет настроен отдельный файл xxx-servlet.xml. Но applicationContext.xml будет общим для всех файлов конфигурации сервлета. Spring по умолчанию загрузит файл с именем «xxx-servlet.xml» из папки WEB-INF вашего веб-приложения, где xxx - это имя сервлета в web.xml. Если вы хотите изменить имя этого файла или изменить местоположение, добавьте initi-param с contextConfigLocation в качестве имени параметра.
Сравнение и связь между ними:
ContextLoaderListener против DispatcherServlet
ContextLoaderListener создает корневой контекст приложения. Записи DispatcherServlet создают один дочерний контекст приложения для каждой записи сервлета. Дочерние контексты могут обращаться к bean-компонентам, определенным в корневом контексте. Бины в корневом контексте не могут получить доступ к бинам в дочерних контекстах (напрямую). Все контексты добавляются в ServletContext. Вы можете получить доступ к корневому контексту, используя класс WebApplicationContextUtils.
После прочтения документации Spring, следующее понимание:
a) Контексты приложения являются иерархическими, как и WebApplicationContexts. Обратитесь к документации здесь.
b) ContextLoaderListener создает корневой контекст веб-приложения для веб-приложения и помещает его в ServletContext. Этот контекст может использоваться для загрузки и выгрузки bean-компонентов, управляемых пружиной, независимо от того, какая технология используется на уровне контроллера (Struts или Spring MVC).
c) DispatcherServlet создает свой собственный WebApplicationContext, и обработчики / контроллеры / view-resolvers управляются этим контекстом.
d) Когда ContextLoaderListener используется в тандеме с DispatcherServlet, сначала создается корневой контекст веб-приложения, как было сказано ранее, а дочерний контекст также создается DispatcherSerlvet и присоединяется к корневому контексту приложения. Обратитесь к документации здесь.
Когда мы работаем с Spring MVC и также используем Spring на уровне сервисов, мы предоставляем два контекста приложения. Первый настраивается с использованием ContextLoaderListener, а другой - с помощью DispatcherServlet.
Как правило, вы определяете все связанные с MVC компоненты (контроллер и представления и т. Д.) В контексте DispatcherServlet, а также все сквозные компоненты, такие как безопасность, транзакции, службы и т. Д., В корневом контексте с помощью ContextLoaderListener.
Обратитесь к этому для получения более подробной информации: https://siddharthnawani.blogspot.com/2019/10/contextloaderlistener-vs.html
источник
По сути, вы можете изолировать контекст корневого приложения и контекст веб-приложения, используя ContextLoaderListner.
Файл конфигурации, сопоставленный с параметром контекста, будет действовать как конфигурация контекста корневого приложения. И файл конфигурации, сопоставленный с сервлетом диспетчера, будет вести себя как контекст веб-приложения.
В любом веб-приложении у нас может быть несколько сервлетов-диспетчеров, поэтому несколько контекстов веб-приложения.
Но в любом веб-приложении у нас может быть только один корневой контекст приложения, общий для всех контекстов веб-приложения.
Мы должны определить наши общие службы, сущности, аспекты и т. Д. В контексте корневого приложения. А контроллеры, перехватчики и т. Д. Находятся в соответствующем контексте веб-приложения.
Пример файла web.xml:
Здесь класс конфигурации example.config.AppConfig может использоваться для настройки служб, объектов, аспектов и т. Д. В контексте корневого приложения, который будет использоваться всеми остальными контекстами веб-приложения (например, здесь у нас есть два класса конфигурации контекста веб-приложения RestConfig и WebConfig)
PS: Здесь ContextLoaderListener является полностью необязательным. Если мы не будем упоминать ContextLoaderListener в web.xml здесь, AppConfig не будет работать. В этом случае нам нужно настроить все наши сервисы и объекты в WebConfig и Rest Config.
источник
Это даст вам возможность поместить некоторый код, который вы хотите выполнить, во время развертывания веб-приложения.
источник
Класс слушателя - прослушивает событие (например, запуск / завершение работы сервера)
ContextLoaderListener -
Файлы конфигурации могут быть предоставлены как это в web.xml
источник
В контексте Spring Framework целью ContextLoaderListener является загрузка других bean-компонентов в вашем приложении, таких как компоненты среднего уровня и уровня данных, которые управляют серверной частью приложения.
источник
Ваше понимание верно. Интересно, почему вы не видите никаких преимуществ в ContextLoaderListener. Например, вам нужно построить фабрику сессий (для управления базой данных). Эта операция может занять некоторое время, поэтому лучше сделать это при запуске. Конечно, вы можете сделать это с помощью сервлетов init или чего-то еще, но преимущество подхода Spring состоит в том, что вы конфигурируете без написания кода.
источник
Если мы напишем web.xml без ContextLoaderListener, то мы не сможем дать аутентификацию, используя customAuthenticationProvider в весенней безопасности. Поскольку DispatcherServelet является дочерним контекстом ContextLoaderListener, customAuthenticationProvider является частью parentContext, который является ContextLoaderListener. Поэтому родительский контекст не может иметь зависимости дочернего контекста. И поэтому лучше всего написать spring-context.xml в contextparam вместо того, чтобы записывать его в initparam.
источник
Я считаю, что его реальное использование происходит, когда вы хотите иметь более одного конфигурационного файла или у вас есть файл xyz.xml вместо applicationcontext.xml для, например,
<context-param><param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/training-service.xml, /WEB-INF/training-data.xml</param-value> </context-param>
Другой подход к ContextLoaderListener заключается в использовании ContextLoaderServlet, как показано ниже
<servlet> <servlet-name>context</servlet-name> <servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet>
источник