Spring Reference 3장

Bean Life Cycle

<참조>Spring In Action 48쪽[Spring 3] BeanFactory와 ApplicationContext 내의 Bean의 LifecycleSpring API :: BeanFactory

Vlidator - Property 파일 사용하기

이전 글에서 사용한 방법으로는 입력 필드에 값이 비어있는지만 확인할 수 있습니다. 아마도 Errors 객체를 사용할 때 값이 비어있는지 검사하려면 if 문이 자주 사용되니까 그 코드를 줄여주기 위해 만든것 같습니다. 따라서 빈 값인지 확인할 때는 유용하게 사용할 수 있지만 그 이외의 경우에는 Errors 인터페이스를 사용해야 한다.Errors의 인터페이스 중에 에러 메시지를

Spring Reference 3장

Bean Life Cycle 콜백 인터페이스 사용 예(in Spring)

BeanNameAware– ServletForwardingController– AbstractView– PortletWrappingController– GenericFilterBean– JobDetailBean– OsgiServiceProxyFactoryBean– AbstractTest– EhCacheFactoryBean– FieldRetrievingFactoryBean BeanClassLoaderAware– 구현 방법 : this.beanClassLoader = (beanClassLoader != null ? beanClassLoader : ClassUtils.getDefaultClassLoader());– AbstractBeanFactory– AbstractBeanDefinitionReader ::– ConfigurableBeanFactory 인터페이스 ::– AbstractHttpInvokerRequestExecutor– HttpInvokerTests BeanFactoryAware– MethodLocatingFactoryBean– ProxyFactoryBean= AbstractAdvisorAutoProxyCreator– AbstractBeanFactoryBasedTargetSourceCreator–

Bean Life Cycle

머리 뽀개지는 BeanPostProcessor

이전 글에서 모든 Bean Life Cycle 콜백들을 구현하여 모든 콜백들이 예상대로 동작하는지 확인해봤습니다. 모든 메소드들이 제대로 동작했지만 BeanPostProcessor만 이상하게 동작하지 않았습니다. 결론부터 말씀드리면 재미없기 때문에 일단 코드를 보겠습니다. <bean id=”test” class=”net.agilejava.jedi.spring.beanLifeCycle.BeanLifeCycleTestBean” init-method=”customInit” />

Bean Life Cycle

Bean Life Cycle 통째로 테스트

Bean Life CycleBeanNameAware 테스트BeanClassLoaderAware 테스트BeanFactoryAware 테스트MessageSource 사용 예ApplicationEvent 사용 예MessageSource 사용 예BeanPostProcessor 사용 예 다 비슷한 테스트 들인데 하나씩 테스트 하기가 지겨워서 Bean Life Cycle에 관여하는 모든 인터페이스를 전부 구현하도록 했습니다. /** * */package net.agilejava.jedi.spring.beanLifeCycle; import javax.servlet.ServletContext; import org.springframework.beans.BeansException;import org.

BeanFactoryAware

BeanFactoryAware 테스트

@Test public void testBeanFactoryAware() { BeanFactory beanFactory = bean.getBeanFactory(); assertNotNull(beanFactory); } 테스트 코드는 간단합니다. 이전 글에 사용했던 클레스에 BeanFactoryAware 인터페이스를 추가로 구현합니다. public class BeanLifeCycleTestBean implements BeanFactoryAware, … { … 생략

Bean Life Cycle

BeanClassLoaderAware 테스트

이전 글에서 사용한 Bean 클레스에 BeanClassLoaderAware 인터페이스를 추가로 구현합니다. public class BeanLifeCycleTestBean implements BeanNameAware, BeanClassLoaderAware{ String beanName; ClassLoader classLoader; public void setBeanName(String beanName) { System.out.println(“setBeanName() 실행합니다.”); this.beanName = beanName;

BeanLifeCycle

BeanNameAware 테스트

public class BeanLifeCycleTestBean implements BeanNameAware{ String beanName; public void setBeanName(String beanName) { this.beanName = beanName; } public String getBeanName(){ return beanName; } } 위와 같이 BeanNameAware 클레스를 구현해

<aop:scoped-proxy/>

3.4.3. The other scopes

2.0에 새로 추가 된 Bean의 Scope들로 request, session, global session이 있습니다. 그리고 이 Scope들은 웹에서 사용하도록 만들어진 것이기 때문에 web-based applicationContext에서만 사용할 수 있습니다. 안그러면 IllegalStateException 이게 발생합니다. web-based applicationContext 란?WebApplicationContext 인터페이스를 구현한 클래스들로 다음과 같습니다. AbstractRefreshablePortletApplicationContext, AbstractRefreshableWebApplicationContext, GenericWebApplicationContext, StaticPortletApplicationContext, StaticWebApplicationContext, XmlPortletApplicationContext, XmlWebApplicationContext 물론 위에서 abstract와 generic(여러

Circural Reference

Circular dependencies

참조 : Spring Reference 3.3.1.2의 오른쪽 회색 박스 Circular dependencies[footnote]이전 글에서 모르겠다고 했던 circular reference를 다르게 IoC챕터 답게 표현한듯…[/footnote]는 간단하게 교착상태에 비유할 수 있을 것 같습니다. Constructor Injection을 사용할 때 발생할 수 있는 문제로 예를 들어 A라는 클래스의 인자로 B 클래스 타입의 객체가

Spring Basic

연습 문제 풀다가 모르는 것 체크

It is a good idea to use constructor injection instead of setter injection to evade circular reference. = FALSE => evade circular reference. 이게 뭐지..Circular dependencies The prototype-scoped beans ignore lazy-init attribute of bean element of the wiring configuration file only if the bean is instantiated using plain

Spring Basic 시험

Java Black Belt :: Spring Basic 시험 결과

틀린 문제 정리.. constructor 인자 구별하는 문제였는데 틀렸네요.ㅠ.ㅠ 흠.. 그럼 싱글톤인 빈은 불려지려나.. 이런 실수를.. 말장난에 속아버리다니.. 흠냐.. 이벤트와 ApplicationCotext 관련 문젠데…틀렸네요.

resources

4. Resources

참조 : http://static.springframework.org/spring/docs/2.0.x/reference/resources.html 4.1. Introduction java.util.URL 클래스와 URL의 prefix를 다루는 표준 핸들러들로는 부족하다. 참조하는 파일이 존재 하는지 체크하는 등의 메소드가 없다. 4.2. The Resource interface Spring의 Resource 인터페이스는 그 보다 좀 더 풍부한 기능을 제공 하도록

MessageSource

MessageSource 사용 예

ApplicationContext가 MessageSource 인터페이스를 구현했기 때문에 ApplicationContext를 MessageSource 처럼 사용할 수 있습니다. greeting에 관한 메시지를 받아 오는 예제를 작성해 보겠습니다. @Test public void messageSource(){ MessageSource messageSouce = bf; assertTrue(messageSouce.getMessage(“greeting”, null, “Default”, null).

MessageSource 인터페이스

Strategy interface for resolving messages, with support for the parameterization and internationalization of such messages. MessageSource 인터페이스에 있는 메소드들은 다음과 같습니다. 이 인터페이스를 구현한 클래스들은 다음과 같습니다. AbstractApplicationContext, AbstractMessageSource, AbstractRefreshableApplicationContext, AbstractRefreshablePortletApplicationContext, AbstractRefreshableWebApplicationContext, AbstractXmlApplicationContext, ClassPathXmlApplicationContext, DelegatingMessageSource, FileSystemXmlApplicationContext, GenericApplicationContext, GenericWebApplicationContext, ReloadableResourceBundleMessageSource, ResourceBundleMessageSource, StaticApplicationContext, StaticMessageSource, StaticPortletApplicationContext, StaticWebApplicationContext, XmlPortletApplicationContext, XmlWebApplicationContext 이 중에서 Reference와 MessageSource

ApplicationContext

3.8. The ApplicationContext

3.8.1. Internationalization using MessageSourcesMessageSource 인터페이스를 상속하고 있기 때문에 다음의 메소드들을 사용하여 Message를 받아 올 수 있습니다. ApplicationContext가 로딩 될 때 context에 정의되어 있는 MessageSource를 자동으로 읽어 들입니다. 이때 bean의 이름은 messageSource 여야 합니다. MessageSource 인터페이스 (2)MessageSource 사용 예3.8.2. Events ApplicationEvent 클래스와 ApplicationListener 인터페이스를 사용해서 ApplicationContext에서

BeanFactoryPostProcessor

BeanFactoryPostProcessor 사용 예

BeanFactoryPostProcessor 인터페이스에는 메소드가 하나 있습니다. void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) 이 인터페이스를 구현한 클래스들 입니다. CustomEditorConfigurer, CustomScopeConfigurer, PreferencesPlaceholderConfigurer, PropertyOverrideConfigurer, PropertyPlaceholderConfigurer, PropertyResourceConfigurer, ServletContextPropertyPlaceholderConfigurer 언제 사용 하면 좋을지는.. 공부를 더 해봐야겠네요. 일단은 Java Developement with Spring 책에 있는 예제[footnote]bean factory가 가지고 있는 모든 bean을 출력하는 BeanFactoryPostProcessor[/footnote]를 사용해 보겠습니다. public

BeanPostProcessor

BeanPostProcessor 사용 예

BeanPostProcessor 인터페이스는 다음과 같습니다.이 인터페이스를 구현한 클래스들 입니다. 유용하니까 만들어 뒀을 텐데 언제 어떤걸 사용하면 좋을지는 나~~~중에 알아봐야겠네요. AbstractAdvisorAutoProxyCreator, AbstractAutoProxyCreator, ActionServletAwareProcessor, AdvisorAdapterRegistrationManager, AnnotationAwareAspectJAutoProxyCreator, ApplicationContextAwareProcessor, AspectJAwareAdvisorAutoProxyCreator, BeanNameAutoProxyCreator, DefaultAdvisorAutoProxyCreator, InstantiationAwareBeanPostProcessorAdapter, PersistenceAnnotationBeanPostProcessor, PersistenceExceptionTranslationPostProcessor, PortletContextAwareProcessor, RequiredAnnotationBeanPostProcessor, ScriptFactoryPostProcessor, ServletContextAwareProcessor, SimplePortletPostProcessor, SimpleServletPostProcessor SIA(Spring In Action) 74쪽 부터 몇 장에 걸쳐 postProcessAfterInitialization 메소드를 사용하는

Container extension points

3.7. Container extension points

3.7.1. Customizing beans using BeanPostProcessors Bean의 LifeCycle을 보면 initailization을 하기 전 과 후에 어떤 작업을 추가할 수 있는 인터페이스로 보입니다. BeanPostProcessor 사용 예3.7.2. Customizing configuration metadata with BeanFactoryPostProcessors BeanPostProcessor와 비슷하지만 적용되는 대상이 Configuration Metadata 입니다. bean을 만들고 DI하기 전에 설정 내용을 변경할 수 있습니다. BeanFactoryPostProcessor 사용

destroy-method

init-method & destroy-method

dk78.bmp이 전 글에서 사용한 방식으로 Bean의 LifeCycle에 끼어들 수도 있지만 InitializingBean이나 DisposableBean과 같은 Spring 프레임웤 소스에 종속성이 생기게 됩니다. <bean /> 태그의 init-method 와 destroy-method 속성을 이용하여 initializingBean과 DisposableBean을 대체 할 수 있습니다.1. 초기화 메소드와 소멸자 메소드 이름을 마음대로 정할 수 있습니다.2. Spring 프레임웤 종속성이 생기지

Spring Reference 3장

The IoC container

3.1. Introduction 이번 장에서는 Spring 프레임웤이 구현한 IoC에 관해 다룹니다. IoC는 Spring이 제공하는 여러 기능들에 가장 기본이 됩니다. IoC 컨테이너의 기능은 BeanFactory와 ApplicationContext 인터페이스를 통해 제공되며 BeanFactory가 객체를 관리하기 위한 기본적인 기능을 제공하는 반면 ApplicationContext는 거기에 추가해서 보다 다양한 기능을 제공합니다. BeanFactory와 ApplicationContext 인터페이스 비교 3.2. Basics –

Customizing bean

3.5. Customizing the nature of a bean

3.5.1. Lifecycle interfaces Spring container에서 사용된는 bean의 lifecycle에 부가적인 일을 추가할 수 있습니다. InitializingBean 과 DisposableBean 같은 인터페이스를 구현 하면 됩니다. 하지만 그렇게 되면 코드가 Spring 프레임웤에 종속성이 생기기 때문에 다른 방법도 있습니다. Bean’s Life CycleInitializingBean & DisposableBeaninit-method & destroy-method3.5.2. Knowing who you are

Bean Scope

Singleton & Prototype

<bean /> 엘리먼트의 scope 속성을 사용하여 bean의 scope을 지정해 줄 수 있습니다. default 값은 singleton입니다. <bean id=”email2″ class=”beanConfiguration.Email” /> <bean id=”keesun6″ class=”beanConfiguration.Member”> <property

Bean Scopes

3.4. Bean scopes

설정 파일에서 bean들을 정의하고 다른 bean들 과의 종속성을 정의 하는 것 말고도 각각 bean들의 scope을 설정해 줄 수 있습니다. Scope Description singleton Spring Ioc 컨테이너 내에서 bean 정의 당 하나의 객체 prototype 매번 같은 Type의 새로운의 객체 request Http request 당 하나 씩, web-aware ApplicationContext session Http session 당 하나

Autowiring

<bean /> 엘리먼트의 autowire 속성을 사용하여 bean들을 자동으로 묶을 수 있습니다. autowire에 지정할 수 있는 값은 다섯가지가 있습니다. no : 기본값입니다. autowire를 사용하지 않겠다는 겁니다.byName : bean의 property 이름으로 다른 bean을 찾아서 연결합니다.byType : bean의 property 타입으로 다른 bean을 찾아서 연결합니다. 같은 type의 bean이 여러개면 에러가 발생합니다.constuctor : byType과