Spring Framework – первые шаги (Конспект пятый)

В предыдущей лекции мы определились, что Application context – это описание среды окружения, т.е. в файловой системе он может присутствовать как набор конфигурационных файлов.

Конспект пятый : Application context (продолжение)

В то же время, в библиотеке классов Spring Framework существует интерфейс org.springframework.context.ApplicationContext, предоставляющий следующие возможности:

  • фабричные методы для доступа к компонентам приложения;
  • возможность загрузки файлов ресурсов;
  • поддержку i18n;
  • наследование от родительского контекста;
  • etc.

Существует несколько способов „поднятия“ application context. Для иллюстрации я остановлюсь на простейшем способе, который с успехом можно использовать при разработке юнит тестов. Давайте рассмотрим его пример:

package com.personality.examples.spring.ioc;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;

public class Main {

	public static void main(String[] args) {

		ApplicationContext ctx =
                        new FileSystemXmlApplicationContext(
			registratoApplicationContext.xml");
		RegisterFormControllerReadyForIoC controller =
			(RegisterFormControllerReadyForIoC)
                        ctx.getBean("registerFormController");

		controller.send();
	}
}

Как видно из примера, первой строкой метода main, мы загружаем контекст приложения из файла registratoApplicationContext.xml (см. предыдущую лекцию). После чего, с помощью метода getBean() у нас появляется возможность получить доступ ко всем компонентам, объявленным в соответствующем контексте.

Однако следует отметить тот факт, что единого мнения о пользе „вынесенного конфигурирования в отдельный xml файл“ нет. С одной стороны, у нас складывается впечатление, что конфигурирование, вынесенное за рамки кода, позволяет выполнять его (конфигурирование) не программистом системы, а скажем администратором!? C другой стороны, Мартин Фаулер в своих статьях ставит под сомнение тот факт, что подобное конфигурирование может выполнить человек не посвященный в таинства всей системы, ну и кроме того получается, что каждая платформа обрастает своими конфигурационными файлами: у Spring свой формат xml-файлов, у Struts – свой, jBoss, TomCat… etc. Т.о. разрабочик все время должен держать себя в тонусе и отслеживать все изменения, происходящие в Java-сообществе, для того чтобы не выпасть из обоймы ;).

Очевидно, что все вышесказанное заставляет задуматься архитекторов о том, чтобы привести декларативное конфигурирование системы к единому стандарту, понятному всем Java разработчикам. Альтернативным подходом в данном случае является использование анотаций, появившихся в J2SE 5.0. И работы в этом направлении ведутся. Это подтверждает и появление EJB 3.0, и наметившийся трэнд в Spring Framework – с каждой новой версией разработчики Spring поддерживают все большее количество анотаций, позволяющих сконфигурировать систему непосредственно в коде приложения. Сейчас мы не будем останавливаться на этих возможностях Их мы рассмотрим в одной из следующих лекций.

Ну, и на последок, я бы предложил читателю ознакомиться с еще одним вариантом, „поднятия“ контекста приложения в рамках Servlet-контейнера (например, TomCat 5.5.x). Рассмотрим соответствующий web.xml:

<web-app>
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>
			/WEB-INF/registratorApplicationContext.xml
		</param-value>
	</context-param>

	<servlet>
		<servlet-name>registratorapp</servlet-name>
		<servlet-class>
			org.springframework.web.servlet.DispatcherServlet
		</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>

	<servlet-mapping>
		<servlet-name>registratorapp</servlet-name>
		<url-pattern>*.do</url-pattern>
	</servlet-mapping>

</web-app>

Как видите, ничего сверхсложного нет. При анализе кода следует, пожалуй обратить внимание на текст выделенный красным цветом. Расположение файлов конфигурации описывается в тэге <context-param>. Далее, загруженный Front Controller (org.springframework.web.servlet.DispatcherServlet), „поднимает“ контекст приложения, после чего все компоненты, описанные в файле конфигурации, опять-таки статновятся доступны, но теперь уже из web приложения.

This entry was posted in Java, Main menu and tagged . Bookmark the permalink.
  • Александр

    Здорово! Спасибо!
    Три дня читал книги, мануалы. И только здесь очень многое понял.

    • Роман

      Ну на самом деле если бы ты прочитал это не почитав три дня что-нибудь ещё, то вряд ли бы ты понял всё это так же))

  • Valery

    *опечатка
    позволяющих вконфигурировать систему