Spring Reference 3장

A collection of 32 posts

Errors

Vlidator - Property 파일 사용하기

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

Bean Life Cycle

머리 뽀개지는 BeanPostProcessor

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

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

&lt;aop:scoped-proxy/&gt;

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,

MessageSource 인터페이스

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,

ApplicationContext

3.8. The ApplicationContext

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

BeanFactoryPostProcessor

BeanFactoryPostProcessor 사용 예

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

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쪽 부터

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하기 전에 설정

destroy-method

init-method &amp; destroy-method

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

Spring Reference 3장

The IoC container

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

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.

You've successfully subscribed to Whiteship!
Could not sign up! Invalid sign up link.