룩업 메소드 인젝션
2007년 11월 8일 목요일
2007년 11월 7일 수요일
2장 빈 묶기(Wiring Beans)
2.1 컨테이너 안의 빈
스프링 컨테이너
org.springframework.beans.factory
org.spirngframework.context.ApplicationContext
2.1.1 빈 팩토리 개요
다양한 유형의 빈을 생성하고 분배할 수 있다.
협업하는 객체 간의 연관관계를 생성시키는 것이 가능하다.
커스텀 초기화 메소드(initialization method)와 소멸 메소드(destruction method)를(만약 정의돼 있다면) 호출함으로써 빈의 생명주기에 개입할 수 있다.
BeanFactory factory = new XmlBeanFactory(new FileInputStrea("beans.xml"));
빈 팩토리가 빈의 정의는 즉시 로딩하는 반면, 빈 자체가 필요하게 되기 전까지는 인스턴스화하지 않는다.
BeanFacoty로부터 빈을 얻어오기 위해서는, 다음과 같이 원하는 빈의 이름을 getBean()메소드에 전달하여 호출
MyBean myBean = (MyBean)factory.getBean("myBean");
2.1.2 애플리케이션 컨텍스트로 작업하기
- 애플리케이션 컨텍스트는 국제화(I18)지원을 포함해 텍스트 메시지를 해석
- 애플리케이션 컨텍스트는 이미지 등과 같은 자원을 로딩하는 범용적인 방법을 제공
-애플리케이션 컨텍스트는 리스터로 등록돼있는 빈에 이벤트를 발행할 수 있다.
2.2.2 빈 추가
- 프로토타입과 싱클톤 비교
의 singleton 특성은 빈이 싱클톤으로 정의될 것인지의 여부를 나타낸다. 기본 값이 true이지만, false로 설정하면 빈이 프로토타입으로 정의 된다.
2.2.4 생성자를 통한 의존성 주입
42
* 모호한 생성자 인자의 처리
index 속성 추가
http://www.manning.com
http://www.springinaction.com
type 속성 이용
http://www.manning.com
http://www.springinaction.com
-생성자와 세터 비교
생성자 주입 장점
1) 의존성 계약을 강제한다.
2) 불필요한 세터 메소드를 가질 필요가 없다.
3)특성이 변경되지 않는 특성(immutable property)효과
세터 주입 장접
1)빈이 여러 개의 의존성을 갖는 경우에는 생성자의 파라미터 목록이 매우 길어진다.
2)유효한 객체를 구성하는 다양한 방법이 존재한다면, 오직 파라미터의 수와 타입에 의해 생성자의 시그너처(signature)가 다양해질 것이므로 특정한 생성자를 식별하기가 어려워진다.
3)만약 생성자가 동일한 타입의 두 개 이상의 파라미터를 취한다면, 각 파라미터의 목적을 팡ㄱ하기 어려원질 것이다.
4) 생성자 주입은 그 자체로 즉시 상속에 사용할 수 없다. 부모 객체의 private 특성을 설정하기 위해서는 빈의 생성자에서 항상 파라미터를 super()로넘겨야 할 것이다.
2.3 자동 묶기
-byName:
묶고자 하는 특성의 이름과 동일한 이름이나 ID를 가진 빈을 컨테이너에서 찾는다.
-byType:
묶고자 하는 특성의 타입과 동일한 타입을 가진 빈을 컨테이너에서 찾는다.
-constructor:
묶고자 하는 빈의 생성자 중 하나의 파라미터와 맞는 하나 이상의 빈을 컨테이너에서 찾는다.
-autodetect:constructor에 의한 자동 묶기를 먼저 시도한 다음, byType을 이용한다.
묶기 적용
byName으로 자동 묶기를 함으로써 컨테이너 CourseServiceImple의 모든 특성을 고려하고 동일한 이름으로 선언된 빈을 찾는다.
2.4 스프링의 스페셜 빈으로 작업하기
- 빈의 설정을 후처리(postProcessing)함으로써 빈의 생명주기오 빈 팩토리의 생명주기에 관여할 수 있다.
- 외부 프로퍼티 파일로부터 설정 정보를 읽어올 수 있다.
- 빈의 특성을 설정할 때 String 값이 다른 타입으로 자동 변환되도록 스프링의 의존성 주입을 변경할 수 있다.
- 프로퍼티 파일로부터 텍스트 메시지(국제화된 메시지 포함)를 읽어올 수 있다.
- 다른 빈들 또느 스프링 컨테이너거 직접 발행한 애플리케이션 이벤트를 청취(listening)하고 응답할 수 있다.
-스피링 컨테이너에서 빈 자신의 정체성을 인식할 수 있다.
2.4.1 빈의 후처리빈의 생명주기에 끼어들어 빈의 설정을 재검토하거나 바꿀 수 있는 2개의 기회를 제공한다.
바로 이것을 후처리라고 한다.
후처리는 그 이름으로 미뤄보아 어떤 이벤트가 발생한 후에 처리되는 것이라고 추측할 수 있다.여기서 이벤트란 빈이 설정되거나 인스턴스화되는 것을 말한다.
public interface BeanPostProcessor{
Object postProcessBeforeInitialization(Object bean, String name) throws BeansException;
Object postProcessAfterInitialization(Object bean, STring name) throws BeansException;
}
postProcessBeforeInitialization()메소드는 빈이 초기화(afterPropertiesSet()이나 빈의 커스텀 init-method 호출)되기 직전에 호출된다.마찬가지로 postProcessAfterInitialization()메소드는 빈이 초기화된 직후에 호출된다.
- 후처리기 작성
public class Fuddifier implements BeanPostProcessor{
public Object postProcessAfterInitialization(Object bean, String name) throws BeansException{
Field[] fields=bean.getClass().getDeclaredFields();
try{
for(int i=0; i
컨테이너는 fuddifier빈을 BeanPostProcessor로서 인식할 것이며, 각각의 빈이 초기화하기 전과 후에 후처리 메소드를 호출할 것이다.
fuddifier 빈을 상요한 결과로서 모든 빈의 모든 String 특성은 퍼드식으로 변환될 것이다.예를 들어 xml 에 다음과 같이 정의된 빈이 있다고 가정하자.
That rascally rabbit!
"That wascawwy wabbit!"
2.4.2 빈 팩토리의 후처리
BeanPostProcessor는 빈이 로딩된 후에 빈의 후처리를 수행하는 반면, BeanFactoryPostProcessor는 빈 팩토리가 빈의 정의를 로딩한 후와 빈이 인스턴스화 되기 전에 빈 팩토리에 대해 후처릴를 수행한다.BeanFactoryPostProcessor 인터페이스는 다음과 같이 저의돼있다.
public interface BeanFactory PostProcessor{
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException;
}
postProcessBeanFactory()메소드는 모든 빈의 정의가 로딩된 다음, BeanPostProcessor빈을 포함한 어떤 빈이라도 인스턴스화됙 이전에 스프링 컨테이너에 의해 호출된다.
public class BeanCounter implements BeanFactoryPostProcessor{ private Logger LOGGER = logger.getLogger(BeanCounter.class);
public void postProcessBeanFactory{
ConfigurableListableBeanFactory factory)
throws BeansException
{
LOGGER.debug("BEAN CO8UNT: " + factory.getBeanDefinitionCount());
}
}
만약 애플리케이션 컨텍스트 컨테이너를 사용한다면 BeanFactoryPostProcessor를 일반적인 빈과 마찬가지로 다음과 같이 등록
BeanFactoryPostProcessor의 유용한 구현 클래스
-PropertyPlaceholderConfigurer하나 이상의 외부 프로퍼티 파일로부터 특성들을 로딩하고 그 특성들을 이용하여 빈 묶기 XML 파일에서 위치소유자(placeholder)변수들을 채운다.
-CustomEditorConfigurerjava.beans.ProeprtyEditor의 커스텀 구현 클래스를 등록하여 특성 값을 다른 타입으로 번역할 수 있도록 한다.
2.4.3 설정 정보의 외부화
ApplicationContext
PropertyPlaceholderConfigurer를 사용하여 외부 프로퍼티 파일로부터 어떤 설정정보를 로딩할 수 있다.
jdbc.properties
location 특성
jdbc.properties
database.url="jdbc:hsqldb.Training
database.dirver=org.hsqldb.jdbcDriver
database.user=appUser
database.password=password
위치소유자 변수로 대체
${database.url}
${database.driver}
${database.user}
${database.password}
2.4.4 특성 편집기 커스터마이징
스프링 컨테이너
org.springframework.beans.factory
org.spirngframework.context.ApplicationContext
2.1.1 빈 팩토리 개요
다양한 유형의 빈을 생성하고 분배할 수 있다.
협업하는 객체 간의 연관관계를 생성시키는 것이 가능하다.
커스텀 초기화 메소드(initialization method)와 소멸 메소드(destruction method)를(만약 정의돼 있다면) 호출함으로써 빈의 생명주기에 개입할 수 있다.
BeanFactory factory = new XmlBeanFactory(new FileInputStrea("beans.xml"));
빈 팩토리가 빈의 정의는 즉시 로딩하는 반면, 빈 자체가 필요하게 되기 전까지는 인스턴스화하지 않는다.
BeanFacoty로부터 빈을 얻어오기 위해서는, 다음과 같이 원하는 빈의 이름을 getBean()메소드에 전달하여 호출
MyBean myBean = (MyBean)factory.getBean("myBean");
2.1.2 애플리케이션 컨텍스트로 작업하기
- 애플리케이션 컨텍스트는 국제화(I18)지원을 포함해 텍스트 메시지를 해석
- 애플리케이션 컨텍스트는 이미지 등과 같은 자원을 로딩하는 범용적인 방법을 제공
-애플리케이션 컨텍스트는 리스터로 등록돼있는 빈에 이벤트를 발행할 수 있다.
2.2.2 빈 추가
- 프로토타입과 싱클톤 비교
2.2.4 생성자를 통한 의존성 주입
* 모호한 생성자 인자의 처리
index 속성 추가
type 속성 이용
http://www.springinaction.com
-생성자와 세터 비교
생성자 주입 장점
1) 의존성 계약을 강제한다.
2) 불필요한 세터 메소드를 가질 필요가 없다.
3)특성이 변경되지 않는 특성(immutable property)효과
세터 주입 장접
1)빈이 여러 개의 의존성을 갖는 경우에는 생성자의 파라미터 목록이 매우 길어진다.
2)유효한 객체를 구성하는 다양한 방법이 존재한다면, 오직 파라미터의 수와 타입에 의해 생성자의 시그너처(signature)가 다양해질 것이므로 특정한 생성자를 식별하기가 어려워진다.
3)만약 생성자가 동일한 타입의 두 개 이상의 파라미터를 취한다면, 각 파라미터의 목적을 팡ㄱ하기 어려원질 것이다.
4) 생성자 주입은 그 자체로 즉시 상속에 사용할 수 없다. 부모 객체의 private 특성을 설정하기 위해서는 빈의 생성자에서 항상 파라미터를 super()로넘겨야 할 것이다.
2.3 자동 묶기
-byName:
묶고자 하는 특성의 이름과 동일한 이름이나 ID를 가진 빈을 컨테이너에서 찾는다.
-byType:
묶고자 하는 특성의 타입과 동일한 타입을 가진 빈을 컨테이너에서 찾는다.
-constructor:
묶고자 하는 빈의 생성자 중 하나의 파라미터와 맞는 하나 이상의 빈을 컨테이너에서 찾는다.
-autodetect:constructor에 의한 자동 묶기를 먼저 시도한 다음, byType을 이용한다.
묶기 적용
byName으로 자동 묶기를 함으로써 컨테이너 CourseServiceImple의 모든 특성을 고려하고 동일한 이름으로 선언된 빈을 찾는다.
2.4 스프링의 스페셜 빈으로 작업하기
- 빈의 설정을 후처리(postProcessing)함으로써 빈의 생명주기오 빈 팩토리의 생명주기에 관여할 수 있다.
- 외부 프로퍼티 파일로부터 설정 정보를 읽어올 수 있다.
- 빈의 특성을 설정할 때 String 값이 다른 타입으로 자동 변환되도록 스프링의 의존성 주입을 변경할 수 있다.
- 프로퍼티 파일로부터 텍스트 메시지(국제화된 메시지 포함)를 읽어올 수 있다.
- 다른 빈들 또느 스프링 컨테이너거 직접 발행한 애플리케이션 이벤트를 청취(listening)하고 응답할 수 있다.
-스피링 컨테이너에서 빈 자신의 정체성을 인식할 수 있다.
2.4.1 빈의 후처리빈의 생명주기에 끼어들어 빈의 설정을 재검토하거나 바꿀 수 있는 2개의 기회를 제공한다.
바로 이것을 후처리라고 한다.
후처리는 그 이름으로 미뤄보아 어떤 이벤트가 발생한 후에 처리되는 것이라고 추측할 수 있다.여기서 이벤트란 빈이 설정되거나 인스턴스화되는 것을 말한다.
public interface BeanPostProcessor{
Object postProcessBeforeInitialization(Object bean, String name) throws BeansException;
Object postProcessAfterInitialization(Object bean, STring name) throws BeansException;
}
postProcessBeforeInitialization()메소드는 빈이 초기화(afterPropertiesSet()이나 빈의 커스텀 init-method 호출)되기 직전에 호출된다.마찬가지로 postProcessAfterInitialization()메소드는 빈이 초기화된 직후에 호출된다.
- 후처리기 작성
public class Fuddifier implements BeanPostProcessor{
public Object postProcessAfterInitialization(Object bean, String name) throws BeansException{
Field[] fields=bean.getClass().getDeclaredFields();
try{
for(int i=0; i
컨테이너는 fuddifier빈을 BeanPostProcessor로서 인식할 것이며, 각각의 빈이 초기화하기 전과 후에 후처리 메소드를 호출할 것이다.
fuddifier 빈을 상요한 결과로서 모든 빈의 모든 String 특성은 퍼드식으로 변환될 것이다.예를 들어 xml 에 다음과 같이 정의된 빈이 있다고 가정하자.
"That wascawwy wabbit!"
2.4.2 빈 팩토리의 후처리
BeanPostProcessor는 빈이 로딩된 후에 빈의 후처리를 수행하는 반면, BeanFactoryPostProcessor는 빈 팩토리가 빈의 정의를 로딩한 후와 빈이 인스턴스화 되기 전에 빈 팩토리에 대해 후처릴를 수행한다.BeanFactoryPostProcessor 인터페이스는 다음과 같이 저의돼있다.
public interface BeanFactory PostProcessor{
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException;
}
postProcessBeanFactory()메소드는 모든 빈의 정의가 로딩된 다음, BeanPostProcessor빈을 포함한 어떤 빈이라도 인스턴스화됙 이전에 스프링 컨테이너에 의해 호출된다.
public class BeanCounter implements BeanFactoryPostProcessor{ private Logger LOGGER = logger.getLogger(BeanCounter.class);
public void postProcessBeanFactory{
ConfigurableListableBeanFactory factory)
throws BeansException
{
LOGGER.debug("BEAN CO8UNT: " + factory.getBeanDefinitionCount());
}
}
만약 애플리케이션 컨텍스트 컨테이너를 사용한다면 BeanFactoryPostProcessor를 일반적인 빈과 마찬가지로 다음과 같이 등록
BeanFactoryPostProcessor의 유용한 구현 클래스
-PropertyPlaceholderConfigurer하나 이상의 외부 프로퍼티 파일로부터 특성들을 로딩하고 그 특성들을 이용하여 빈 묶기 XML 파일에서 위치소유자(placeholder)변수들을 채운다.
-CustomEditorConfigurerjava.beans.ProeprtyEditor의 커스텀 구현 클래스를 등록하여 특성 값을 다른 타입으로 번역할 수 있도록 한다.
2.4.3 설정 정보의 외부화
ApplicationContext
PropertyPlaceholderConfigurer를 사용하여 외부 프로퍼티 파일로부터 어떤 설정정보를 로딩할 수 있다.
location 특성
jdbc.properties
database.url="jdbc:hsqldb.Training
database.dirver=org.hsqldb.jdbcDriver
database.user=appUser
database.password=password
위치소유자 변수로 대체
2.4.4 특성 편집기 커스터마이징
2007년 11월 4일 일요일
Chapter 3. The IoC container
3.2. Basics - containers and beans
bean은 container 의 메터 데이터 설정으로 빈들간의 의존성을 및 빈들을 반영한다.
3.2.1. 컨테이너( Container)
3.2.1.1. Configuration metadata
3.2.2. Instantiatiing a container
Resource resource = new FileSystemResource("beans.xml");BeanFactory factory = new XmlBeanFactory(resource);
ClassPathResource resource = new ClassPathResource("beans.xml");BeanFactory factory = new XmlBeanFactory(resource);
ApplicationContext context = new ClassPathXmlApplicationContext
(
new String[] {"applicationContext.xml", "applicationContext-part2.xml"}
);
// of course, an ApplicationContext is just a BeanFactoryBeanFactory factory
//= (BeanFactory) context;
3.2.2.1. Composing XML-based configuration metadata
외부의 정의된 3개의 xml(services.xml, messageSource.xml, themeSource.xml) 정의
3.2.3. The Beans
Spring IoC 컨테이너는 하나 또는 그 이상의 beans를 관리 한다.
빈 구조를 메타 데이터를 참조하여 정의 하는 방법
- 제한된 페키지 클래스 네임(a package-qualified class name):
이미 정의된 클래스로부터 구현된다. 만약 static 팩토리 메소드를 통해 제시된 것이라면 팩토리 클래스가 명시될것이다.
- 빈은 xml에 설정된 요소되로 설정되어질 것이다.(prototype, singleton, autowiring mode, initialization, desctruction callbacks, forth)
- 생성된 빈에 생성자 arguments 나 property 값으로 설정되어 질것이다.
- 빈이 작업할때 다른 빈들을 필요로 할 것이다 그것이 collaborators이다.(also called dependencies).
빈의 요소
class, name, scope, constructor arguments, properties, autowiring mode, dependency checking mode, lazy-ionitialization mode, initialization method, destruction method
3.2.3.1. Naming beans
빈은 하나 또는 그 이사의 아이디(identifiers, names)를 가진다. id 는 반드시 유니크 여야 한다.
만약 하나 이상의 아이디를 가진다면 별칭(aliases)을 고려해야 한다.
xml 기반의 설정으로 했을때 'id' 혹은 'name' 속성이 그 빈의 identifier(s) 이다.
xml정의에서 이 id 이름 제한
- 상수로 정의할 수 없다.
name 속성에 콤마(,), 세미콜론(;), whitespace를 사용할 수 없다.
Please note that you are not required to supply a name for a bean. If no name is supplied explicitly, the container will generate a (unique) name for that bean. The motivations for not supplying a name for a bean will be discussed later (one use case is inner beans).
3.2.3.2. Instantiating beans
bean은 container 의 메터 데이터 설정으로 빈들간의 의존성을 및 빈들을 반영한다.
3.2.1. 컨테이너( Container)
org.springframework.beans.factory.BeanFactory
- XmlBeanFactory class
3.2.1.1. Configuration metadata
3.2.2. Instantiatiing a container
Resource resource = new FileSystemResource("beans.xml");BeanFactory factory = new XmlBeanFactory(resource);
ClassPathResource resource = new ClassPathResource("beans.xml");BeanFactory factory = new XmlBeanFactory(resource);
ApplicationContext context = new ClassPathXmlApplicationContext
(
new String[] {"applicationContext.xml", "applicationContext-part2.xml"}
);
// of course, an ApplicationContext is just a BeanFactoryBeanFactory factory
//= (BeanFactory) context;
3.2.2.1. Composing XML-based configuration metadata
외부의 정의된 3개의 xml(services.xml, messageSource.xml, themeSource.xml) 정의
3.2.3. The Beans
Spring IoC 컨테이너는 하나 또는 그 이상의 beans를 관리 한다.
빈 구조를 메타 데이터를 참조하여 정의 하는 방법
- 제한된 페키지 클래스 네임(a package-qualified class name):
이미 정의된 클래스로부터 구현된다. 만약 static 팩토리 메소드를 통해 제시된 것이라면 팩토리 클래스가 명시될것이다.
- 빈은 xml에 설정된 요소되로 설정되어질 것이다.(prototype, singleton, autowiring mode, initialization, desctruction callbacks, forth)
- 생성된 빈에 생성자 arguments 나 property 값으로 설정되어 질것이다.
- 빈이 작업할때 다른 빈들을 필요로 할 것이다 그것이 collaborators이다.(also called dependencies).
빈의 요소
class, name, scope, constructor arguments, properties, autowiring mode, dependency checking mode, lazy-ionitialization mode, initialization method, destruction method
3.2.3.1. Naming beans
빈은 하나 또는 그 이사의 아이디(identifiers, names)를 가진다. id 는 반드시 유니크 여야 한다.
만약 하나 이상의 아이디를 가진다면 별칭(aliases)을 고려해야 한다.
xml 기반의 설정으로 했을때 'id' 혹은 'name' 속성이 그 빈의 identifier(s) 이다.
xml정의에서 이 id 이름 제한
- 상수로 정의할 수 없다.
name 속성에 콤마(,), 세미콜론(;), whitespace를 사용할 수 없다.
Please note that you are not required to supply a name for a bean. If no name is supplied explicitly, the container will generate a (unique) name for that bean. The motivations for not supplying a name for a bean will be discussed later (one use case is inner beans).
3.2.3.1.1 Aliasing beans
3.2.3.2. Instantiating beans
피드 구독하기:
글 (Atom)