Показаны сообщения с ярлыком Spring. Показать все сообщения
Показаны сообщения с ярлыком Spring. Показать все сообщения

четверг, 28 ноября 2013 г.

Внедрение методов Spring

Прием внедрения методов  позволяет внедрять в компоненты определения целых методов.
Spring предоставляет Java-программистам возможность внедрения методов в Java-классы во время выполнения.

Фреймворк Spring поддерживает две формы внедрения методов:
  •  ‰ замещение  метода    – позволяет во время выполнения заместить существующий метод (абстрактный или конкретный) новой реализацией;
  •  ‰ внедрение метода чтения    – позволяет во время выполнения  заместить существующий метод (абстрактный или конкретный) новой реализацией, возвращающей определенный компонент из контекста Spring.
Пример замещения методов


<bean id="magicBox" class="com.springinaction.springidol.MagicBoxImpl">
      <replaced-method  name="getContents"  replacer="tigerReplacer" />
</bean>
<bean id="tigerReplacer" class="com.springinaction.springidol.TigerReplacer" />

Сейчас в компоненте  magicBox имеется элемент  <replaced-method> . Как следует из названия, этот элемент используется для замены метода новой реализацией. В данном случае атрибут name указывает имя замещаемого метода  getContents().

package com.springinaction.springidol;
import java.lang.reflect.Method;
import org.springframework.beans.factory.support.MethodReplacer; 
public class TigerReplacer implements MethodReplacer {
 public Object reimplement(Object target, Method method, // Подмена
          Object[] args) throws Throwable {             // метода
        return "A ferocious tiger"; // Помещает тигра в ящик
    }
}

Класс TigerReplacer реализует интерфейс  MethodReplacer, требующий реализации единственного метода  reimplement(). Этот метод принимает три аргумента: объект, в котором будет производиться замещение метода, метод, подлежащий замещению, и массив аргументов, принимаемых методом.
Тело метода  reimplement() фактически становится новой реализацией метода  getContents().

Способ применения:
Прием внедрения метода с успехом может использоваться, когда фактическая реализация замещаемого метода не известна до момента развертывания. К этому моменту класс с замещающей реализацией метода можно оформить в виде JAR-файла и поместить его в библиотеку классов (classpath) приложения. 

Пример внедрения метода чтения

Внедрение    через метод чтения – это особый случай внедрения методов, когда объявляется метод (обычно абстрактный), возвращающий компонент определенного типа, но фактически возвращаемый компонент определяется в контексте Spring.

package com.springinaction.springidol;
public abstract class Instrumentalist implements Performer {
    public Instrumentalist() {}
    public void perform() throws PerformanceException {
        System.out.print("Playing " + song + " : ");
        getInstrument().play();   // Используется внедряемый метод
    }                        // getInstrument()
    private String song;
    public void setSong(String song) {
        this.song = song;
    }
    public abstract Instrument getInstrument(); // Внедряемый метод

}

Для поддержки внедрения методов чтения фреймворк Spring предлагает элемент  <lookup-method> . Как и  <replaced-method>, элемент <lookup-method> замещает существующий метод новой реализацией во время выполнения. 

<bean id="stevie" class="com.springinaction.springidol.Instrumentalist">
  <lookup-method name="getInstrument" bean="guitar" />
  <property name="song" value="Greensleeves" />
</bean>

Как и в элементе  <replaced-method>, атрибут  name элемента  <lookup-method> определяет замещаемый метод. Здесь замещается метод getInstrument(). Атрибут  bean определяет компонент, возвращаемый методом getInstrument().

Важно помнить, что при использовании элемента  <lookup-method> для внедрения метода чтения совсем необязательно, чтобы замещаемый метод был методом чтения (то есть методом, имя которого начинается со слова  get). С помощью элемента  <lookup-method> можно заместить любой метод, возвращающий некоторое значение.

Следует также отметить, что даже при том, что прием внедрения методов позволяет замещать их реализации, нет никакой возможности изменить сигнатуру метода. Типы параметров и возвращаемого значения должны оставаться такими, какие они есть. 

понедельник, 25 ноября 2013 г.

Оператор Элвиса или интересности Spring

При использовании трехместного оператора в SpEL выражении возможно использование одного и того же выражения. Например

<property name="song" value="#{kenny.song != null ? kenny.song : 'Greensleeves'}"/> 

Это выражение построено правильно, но в нем имеется повторяющийся элемент – ссылка на свойство kenny.song. Язык SpEL предлагает разновидность трехместного оператора, упрощающую подобные выражения:

<property name="song" value="#{kenny.song ?: 'Greensleeves'}"/>

Как и в предыдущем примере, выражение вернет значение свойства kenny.song или «Greensleeves», если свойство kenny.song равно null. При таком способе использования оператор ?: называют оператором Элвиса. Этим странным названием оператор обязан сравнению со смайликами – если повернуть его на 90 градусов (по часовой стрелке), вопросительный знак будет напоминать прическу знаменитого Элвиса Пресли (Elvis Presley).

Внедрение коллекций в компоненты Spring

А возможно ли с помощью Spring инициализировать свойства, имеющие множество значений, что, если свойство является коллекцией значений? 
Фреймворк Spring предлагает четыре типа элементов определения коллекций, которые пригодятся для конфигурирования значений, являющихся коллекциями.


Элементы  <list>   и  <set>   можно использовать для настройки свойств, которые являются массивами или одной из реализаций java.util.Collection. 
Что касается элементов  <map>   и  <props>  , они соответствуют коллекциям с интерфейсами java.util.Map   и java.util.Properties   соответственно. Эти типы коллекций можно использовать, когда требуется коллекция, состоящая из пар ключ/значение. 

Пример 1 (<list>)
<bean id="hank"
     class="com.springinaction.springidol.OneManBand">
  <property name="instruments">
    <list>
      <ref bean="guitar" />
      <ref bean="cymbal" />
      <ref bean="harmonica" />
    </list>
  </property>
</bean>

Пример 2(<map>)
<bean id="hank" class="com.springinaction.springidol.OneManBand">
  <property name="instruments">
    <map>
      <entry key="GUITAR" value-ref="guitar" />
      <entry key="CYMBAL" value-ref="cymbal" />
      <entry key="HARMONICA" value-ref="harmonica" />
    </map>
  </property>
</bean>

Пример 3(<props>)
<bean id="hank" class="com.springinaction.springidol.OneManBand">
  <property name="instruments">
    <props>
      <prop key="GUITAR">STRUM STRUM STRUM</prop>
      <prop key="CYMBAL">CRASH CRASH CRASH</prop>
      <prop key="HARMONICA">HUM HUM HUM</prop>
    </props>
  </property>
</bean>


Область действия Spring-компонента

По умолчанию все компоненты Spring единичны. Когда контейнер передает компонент (либо через связывание, либо как результат вызова метода контейнера  getBean()  ), всегда будет передан тот же самый экземпляр компонента.
При объявлении  <bean> компонента можно определить область его действия. 

Области действия:
singleton - В каждом контейнере Spring может быть создан только один компонент (по умолчанию)
prototype - Позволяет создавать произвольное количество компонентов (по одному на каждое обращение)
Дополнительные области для Spring-MVC приложений:
request - Область действия компонента ограничивается HTTP-запросом. Может применяться только в веб-приложениях Spring (например, использующих Spring MVC)
session - Область действия компонента ограничивается HTTP-сеансом. Может применяться только в веб-приложениях Spring (например, использующих Spring MVC)
global-session - Область действия компонента ограничивается глобальным HTTP-сеансом. Может применяться только в портлетах

Понятие единичных компонентов ограничено областью действия контекста Spring. В отличие от истинных классов-одиночек, гарантирующих существование единственного экземпляра на каждый загрузчик классов (classloader), для единичных компонентов в Spring гарантируется 
только наличие единственного экземпляра компонента в контексте приложения – ничто не мешает создать экземпляр того же класса традиционным способом или даже создать несколько объявлений <bean> для одного и того же класса.

среда, 20 ноября 2013 г.

Жизненный цикл компонента Spring

1.  Spring создает экземпляр компонента.
2.  Spring внедряет значения и ссылки на компоненты в свойства данного компонента.
3.  Если компонент реализует интерфейс  BeanNameAware, Spring передает идентификатор компонента методу  setBeanName()  .
4.  Если компонент реализует интерфейс  BeanFactoryAware, Spring вызывает метод setBeanFactory()  , передавая ему саму фабрику компонентов.
5.  Если компонент реализует интерфейс  ApplicationContextAware, Spring вызывает метод  setApplicationContext(), передавая ему ссылку на вмещающий контекст приложения.
6.  Если какие-либо из компонентов реализуют интерфейс  BeanPost Processor, Spring вызывает их методы  postProcessBeforeInitialization().
7. Если какие-либо из компонентов реализуют интерфейс InitializingBean, Spring вызывает их методы afterPropertiesSet(). Аналогично, если компонент был объявлен с атрибутом  init-method, вызывается указанный метод инициализации.
8. Если какие-либо из компонентов реализуют интерфейс BeanPostProcessor, Spring вызывает их методы  postProcessAfterInitialization().
9.  В этот момент компонент готов к использованию приложением и будет сохраняться в контексте приложения, пока он не будет уничтожен.
10. Если какие-либо из компонентов реализуют интерфейс DisposableBean, Spring вызывает их методы  destroy()  . Аналогично, если компонент был объявлен с атрибутом  destroy-method, 
вызывается указанный метод.

Про Spring

Тут будут некоторые заметки про Spring. Чтобы, когда потребуется, легко освежать у себя в голове.

Два кита, на которых зиждется Spring это Spring DI и Spring AOP.

По поводу Spring DI можно отметить следующий момент. Благодаря DI объекты получают свои зависимости во время создания от некоторой третьей стороны, координирующей работу каждого объекта в системе. Объекты не создают и не получают свои зависимости самостоятельно – зависимости внедряются в объекты.

Основное преимущество DI – слабая связанность. Если объект взаимодействует со своими зависимостями только через их интерфейсы (ничего не зная о конкретных реализациях или особенностях их создания), зависимости можно будет замещать любыми другими реализациями, без необходимости учитывать эти различия в самом объекте.

Однако для того, чтобы определять какой именно объект был внедрен используется связывание.
Связывание - это процесс создания связей между прикладными компонентами.

Фреймворк Spring поддерживает множество способов связывания компонентов, но наиболее общим из них является способ на основе XML.

В приложении, созданном на основе Spring, контекст приложения загружает определения компонентов и связывает их вместе. За создание объектов, составляющих приложение, и их связывание полностью отвечает контекст приложения.

Аспектно-ориентированное программирование   позволяет оформлять функциональность, используемую в приложении, в виде многократно используемых компонентов.

Системные службы, такие как журналирование, управление транзакциями и безопасность, часто находят свое отражение в компонентах, основная задача которых заключается в чем-то другом. Такие системные службы обычно называют сквозными задачами, потому что в их работу может вовлекаться несколько компонентов  системы.
AOP делает возможным отделение этих служб и декларативное их применение к необходимым компонентам.

Прежде чем использовать волшебство Spring по превращению объекта в аспект, его сначала необходимо объявить компонентом Spring с помощью элемента <bean>. Дело в том, что с аспектами Spring можно выполнять любые операции, которые можно выполнять с другими компонентами Spring, такие как внедрение их в виде зависимостей.

Фреймворк Spring стремится помочь в устранении шаблонного кода путем заключения его в шаблоны. Класс JdbcTemplate из фреймворка Spring позволяет выполнять операции с базой данных без лишних церемоний, требуемых традиционным JDBC.

Фреймворк Spring имеет не один контейнер. В его состав входят несколько реализаций контейнера, которые подразделяются на два разных типа.  Фабрики компонентов  (bean factories) (определяются интерфейсом  org.springframework.beans.factory.BeanFactory ) – самые простые из контейнеров, обеспечивающие базовую поддержку DI.  Контекст приложений  (application contexts) (определяется интерфейсом  org.springframework.context.ApplicationContext ) основан на понятии фабрик компонентов и реализует прикладные службы фреймворка, такие как возможность приема текстовых сообщений из файлов свойств и возможность подписывать другие программные компоненты на события, возникающие в приложении.