ApplicationContext основной серии Spring

Java Spring

ApplicationContext основной серии Spring

Всем привет, с сегодняшнего дня мой брат собирается запустить весеннюю серию блогов, надеюсь всем понравится. На самом деле, мне не нужно больше рассказывать о Spring. Те, кто занимался веб-разработкой, в основном используют Spring, в том числе более модную облачную микросервисную архитектуру Spring. На самом деле она тоже основана на Spring boot. Spring boot — это фактически три традиционных Компоненты Spring. Он просто избегает собственной настройки bean-компонентов пользователем, но принимает автоматическую настройку. Spring boot также будет иметь серию блогов для вас в более поздний период. Этот выпуск — первая статья Spring, начнем с основ, ладно, перейдем к рутине, структура статьи:

  1. Интерфейс ресурсов в Spring.
  2. BeanFactory и ApplicationContext
  3. WebApplicationContext

1. Интерфейс ресурсов в Spring.

На самом деле, этот интерфейс относительно незнаком многим программистам, занимающимся бизнес-разработкой.Все знают, что путь к файлу указывается непосредственно при инициализации контейнера, а затем инициализируется контейнер.Этот ресурсный интерфейс предоставляется Spring, который предоставляет приложению Enhanced доступ к базовым ресурсам. Я не знаю, насколько сильнее, чем классы File и URL, которые поставляются с JDK. Следующая структура класса:

Несколько ключевых моментов: ClassPathResource: возьмите путь к классам в качестве ресурса по относительному пути. FileSystemResource : ресурс, который нужно искать в пути к файловой системе. ServletContextResource: доступ к веб-приложению и каталогу. ByteArrayResource: ресурс, представленный двоичным массивом. Например, в текущем веб-пути есть еще один файл конфигурации Spring, мы можем загрузить его следующим образом:

Resource res =new ServletContectResource(/WEB-INF/classes/spring/application.xml);

Увидев код, я считаю, что более чувствительные друзья должны почувствовать, что этот метод загрузки явно неуместен, потому что при использовании разных типов ресурсов необходимо использовать соответствующий класс ресурса Resource, что более проблематично. Класс реализации ресурса, можно ли получить доступ к соответствующему ресурсу только через специальную идентификацию адреса ресурса? Конечно, с таким замечательным фреймворком, как Spring, это возможно.Spring может не только идентифицировать различные типы ресурсов с помощью префиксов адресов ресурсов, таких как «classpath:», «file», но также поддерживать адреса ресурсов в стиле Ant с подстановочными знаками. Spring будет использовать загрузчик ресурсов для выбора соответствующего класса реализации ресурсов в соответствии с различными путями к ресурсам. Не позволяйте пользователям выбирать свои собственные классы реализации.

1.1 Выражение адреса ресурса

Давайте посмотрим на значение некоторых встроенных префиксов ресурсов Spring:

Затем стиль Ant:

  • ?: Соответствует символу в имени файла.
  • *: соответствует любому символу, указанному в файле.
  • ** : соответствует многоуровневым путям.

Конкретных примеров нет, слишком распространены подстановочные знаки в стиле Ant.

1.2 Загрузчик ресурсов

Я не буду говорить об этих интерфейсах, они не имеют практического значения, скажем только один, PathMatchingResourcePatternResolver, это стандартный загрузчик ресурсов, предоставляемый Spring, который может поддерживать пути ресурсов в стиле Ant и возвращать соответствующий Resource в соответствии с различными типами префиксов. , Например:

public class GaoshiApplication {

	public static void main(String[] args) throws IOException {

		PathMatchingResourcePatternResolver resolver=new PathMatchingResourcePatternResolver();
		Resource[] res =resolver.getResources("file:/Users/zdy/Desktop/sql.txt");
		for (Resource  resource : res){
			System.out.println(resource.getDescription()+"----"+resource.getFilename());
		}
		SpringApplication.run(GaoshiApplication.class, args);
	}
}

输出结果:
URL [file:/Users/zdy/Desktop/sql.txt]----sql.txt

Ну, собственно, почему вы хотите в этом разделе рассказать о загрузчике ресурсов Resource и PathMatchingResourcePatternResolver?Многим может показаться, что он бесполезен.В любом случае, Spring может использовать его внутренне, и это не имеет никакого отношения ко мне. На самом деле это не так.Старые утюги,правда,внутренне используется Spring.Во-первых,плохо ли знать базовые принципы? Второй,Если у вас есть файл конфигурации в пути к классам, а затем вы хотите загрузить его через код (хотя это требование очень мало), то вы можете самостоятельно использовать загрузчик ресурсов, предоставленный Spring. Этот загрузчик по-прежнему очень удобен, загружая ресурсы прямо по префиксу, а также поддерживает подстановочные знаки Ant. Вы говорите отлично или нет.

2. BeanFactory и ApplicationContext

2.1 BeanFactory

BeanFactory, на самом деле, многие о ней слышали, но не использовали.Каждый может использовать класс реализации ApplicationContext при запуске контейнера, так что эта BeanFactory постепенно затухает, не говоря уже о ее классе реализации. Назовите следующие черты:

  1. BeanFactory является ленивой загрузкой.Если определенное свойство Bean не введено, после загрузки BeanFacotry будет выдано исключение, пока метод getBean не будет вызван в первый раз; в то время как ApplicationContext инициализируется, проверяется, что способствует проверке вводятся зависимые свойства. ; Поэтому обычно мы выбираем использование ApplicationContext.
  2. ApplicationContext наследуется от BeanFactory и предоставляет более мощные функции.Как правило, используется ApplicationContext.

Затем приведите пример инициализации BeanFactory:

//调用资源加载器加载Spring配置文件
		PathMatchingResourcePatternResolver resolver=new PathMatchingResourcePatternResolver();
		Resource res =resolver.getResource("classpath:/application.xml");
		
		//创建默认Spring提供的BeanFactory实现类
		DefaultListableBeanFactory bf =new DefaultListableBeanFactory();
		
		//BeanDefinition 读取器,专门读取资源到容器
		XmlBeanDefinitionReader reader =new XmlBeanDefinitionReader(bf);
		
		//读取资源进到容器 
		reader.loadBeanDefinitions(res);
		
		//此时容器初始化完毕后可以取里面的bean了.
		bf.getBean("...");

Как видите, код громоздкий и многословный. Функционал BeanFactory все еще относительно слаб, поэтому все должны его понимать.

2.2 ApplicationContext

Этот ApplicationContext на самом деле является контейнером Spring, как часто говорят старые утюги. Поскольку это относительно важно, приведена грубая диаграмма наследования классов:

Назовите несколько важных классов или интерфейсов на следующем рисунке:

  • ApplicationEventPublisher: предоставляет контейнеру возможность публиковать события контекста приложения.
  • ResourcePatternResolver: реализует функцию, аналогичную загрузчику ресурсов, которая может определить конкретный префикс плюс путь в стиле Ant и загрузить его в контейнер.
  • LifeCycle: управляет жизненным циклом бобов в контейнере.
  • ConfigurableApplicationContext: в основном добавлены новые методы refresh() и close(), что делает ApplicationContext полезным для запуска, реляционных и обновляющих функций контекста.
  • ClassPathXmlApplicationContext против FileSystemXmlApplicationContext: Два часто используемых класса реализации ApplicationContext, предоставляемые Spring, первый загружает файлы конфигурации из пути к классу по умолчанию, а второй загружает из файловой системы. Затем инициализируйте ApplicationContext, чтобы увидеть:
ApplicationContext ac =new ClassPathXmlApplicationContext("application.xml");
ApplicationContext ac =new FileSystemXmlApplicationContext(/User/Desktop/application.xml);

ClassPathXmlApplicationContext по умолчанию использует путь к классам, если нет префикса: FileSystemXmlApplicationContext по умолчанию имеет значение file, если нет префикса:

Тогда я скажу еще одну вещь.Контейнер Spring можно не только инициализировать через xml файл, вы должны знать, что аннотация @Configuration также используется для регистрации бинов.Конечно, Spring также предоставляет соответствующий AnnotationConfigApplicationContext.

ApplicationContext context =new AnnotationConfigApplicationContext(Config.class);

Класс Config — это класс, к которому мы добавили @Configuration.

3. WebApplicationContext

На самом деле WebApplicationContext тоже относится к ApplicationContext, зачем выносить его отдельно, ведь он важнее. WebApplicationContext специально подготовлен Spring для веб-приложений. Это позволяет загружать файлы конфигурации из пути относительно корня веб-сайта для завершения инициализации.WebApplicationContext и ServletContext могут быть получены друг от друга..В среде, отличной от веб-приложений, Bean имеет только две области видимости: одиночную и прототипную, а WebApplicationContext добавляет к Bean три новых области: запрос, сеанс и глобальный сеанс. Взгляните на диаграмму наследования классов:

Самые основные XmlWebApplicationContext и AnnotationConfigWebApplicationContext, как все должны были догадаться, один настраивается XML, а другой настраивается @Configuration.

Затем давайте поговорим о том, как WebApplicationContext и ServletContext получают друг друга, что на самом деле очень просто.В WebApplicationContext есть переменная-член ServletContext, и выполняется прямое получение. В ServletContext есть жестко заданный атрибут, который также можно получить напрямую. И Spring предоставляет WebApplicationContextUtils для инкапсуляции этого жестко заданного атрибута.

其实就是直接调用了ServletContext.getAttribute(ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
    public static WebApplicationContext getWebApplicationContext(ServletContext sc) {
        return getWebApplicationContext(sc, WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
    }

Затем я расскажу об инициализации WebApplication.Любой, кто занимался Web, знает, на самом деле, либо настроить ContextLoaderListener в Web.xml, либо настроить самозапускающийся LoaderServlet.На самом деле это относительно просто, я покажу ContextLoaderListener .

  <!-- 加载spring容器 -->
  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath:spring/applicationContext-*.xml</param-value>
  </context-param>
  <listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>

Если запускать контейнер Spring не по xml файлу, а по классу @Configuration, то на самом деле очень просто.

  <context-param>
    <param-name>contextClass</param-name>
    <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
  </context-param>
  <!-- 加载spring容器 -->
  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>com.zdy.Configuration</param-value>
  </context-param>
  <listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>

Настройте для параметра contextClass ApplicationContext значение AnnotationConfigWebApplicationContext, а затем contextConfigLocation будет не расположением указанного файла конфигурации xml, а расположением класса Configuration. Нормально.

Наконец, следует подчеркнуть, что,Благодаря функции Log4j, которая поставляется с контейнером Spring, пользователи могут напрямую поместить файл конфигурации Log4j в путь к классам, и он вступит в силу напрямую., Однако если его нет в пути к классам, необходимо вручную указать расположение файла и запустить слушатель log4j в Web.xml.Я не буду его здесь демонстрировать.Следует отметить, что слушатель или сервлет этого log4j должен находиться в прослушивателе контейнера Spring или перед сервлетом. Не спрашивайте, почему. Так это предусмотрено. Но это обычно не используется, поэтому я просто упоминаю об этом.

Эпилог

Ну, на самом деле, все могут видеть, что когда я говорю о Spring, я все же предпочитаю его использовать.Основные глубокие принципы Spring на самом деле не сильно разработаны. Spring — это высший фреймворк, я думаю, что сначала необходимо понять использование макросов. Позже у меня будет возможность рассказать вам больше о базовой реализации. Я хочу, чтобы все уделили больше внимания следующему весеннему циклу статей.Over,Have a good day .

Категории