요즘 Spring Framework의 소스 코드를 보는 시간이 많아져서  즐겁기도 하고, 배움의 깊이가 깊어지는 것 같아, 행복하기도 하다.(자아 도취 ?, 만족? )

내가 개발자의 길을 고집하는 것은 좋아하는 일을 업으로 살아갈수 있다는 것이다. 좋아하는 것을 한다는 것은 배움에 있어 거부감없이 이해하는 만큼 흡입할 수 있다.
잘 된 코드를 보고 배울 수 있다는 것은 기능에 대한 이해와 더불어 더 많은 것을 보도록 해준다. 예전에 일민이(Toby)가 소스를 보고 공부하라고 했을때는 별로 필요가 없기도 하고, 기능만 알면 개발할 수 있는데라는 얇팍한 마음에 무시했었다. 그러나 지금 보니 참 많은 것을 얻을 수 있었는데, 좀더 빨리 시도할 걸이라는 마음이 든다.

어제는 Spring Framework에서 Singleton 또는 Prototype으로 Bean을 등록하고 사용하기 위해서 getBean() 메소드를 이용하는 것에 대해서 공부했다.
Bean은 기본적으로 ApplicationContext에 HashMap에 담겨져 있고, 필요시 불리우게 되는데, 이는 ApplicationContext를 통해서 Singleton처러 한개의 인스턴트로 동작하기 때문이다.

이에대해서는 일민이가 스프링 포럼을 통해서 질문에 답한 글을 올렸는데, 쉽게 잘 정리 되어 있다.(필독이다.)


web.xml을 통해서 Root ApplicationContext 로 여러 파일들을 읽어 오려면,

 <context-param>
     <param-name>contextConfigLocation</param-name>
     <param-value>
          /WEB-INF/applicationContext.xml  /WEB-INF/schedulingContext-quartz.xml
     </param-value>
 </context-param>

와 같이 추가해 주면, 클래스 패스 아래 정의된 두개의 설정 파일을 읽어 오게 된다.

아니면, 빈 설정 파일에서 다른 설정 파일들을 import해서 읽어 올수 있다.

<beans>
    <import resource="services.xml"/>
    <import resource="resources/messageSource.xml"/>
    <import resource="/resources/themeSource.xml"/>

    <bean id="bean1" class="..."/>
    <bean id="bean2" class="..."/>
</beans>

xml 파일이 커지거나 작업별로 분리할 필요가 있을때 유용하다.

그리고, 다음과 같이 ApplicationContext Interface를 통해서 여러 설정 파일들을 읽어 올수 있다. 이는 테스트할 때 편리하다.

ApplicationContext context = new ClassPathXmlApplicationContext(
        new String[] {"services.xml", "daos.xml"});
BeanFactory factory = context;

Spring MVC를 이용하여 Web Application을 개발할 경우에는
<servlet>
      <servlet-name>image</servlet-name>
      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
      <load-on-startup>2</load-on-startup>
</servlet>

와 같이 설정파일에 정의하게 되는데, Spring의 DispatcherServlet에서 서블릿을 정의하고, 이를 위한 Config 파일을 읽을 때는 기본적인 Naming rule을 따르는데, {servlet-name}-servlet.xml 같은 형식의 파일을 생성하고 정의하면 된다.
위의 경우라면 image-servlet.xml과 같이 사용하면 된다.

오늘도 두서 없이 적었다.

그냥 며칠동안 테스트 코드를 작성하면서, 발견한 사실들에 대해서 겸허히 쓴다.
일민이(Toby)는 나보고 또 Spring Framework Developer Reference를 읽어보라고, 아프게 충고를 했다.

먼저, Test코드를 작성하다 보니,
BeanFactory 의 사용법과 ApplicationContext 의 사용법이 다르다는 사실을 발견했다.
사실 ApplicationContext는 BeanFactory의 인터페이스를 상속받아 만들어진 인터페이스이다. 따라서, ApplicationContext는 BeanFactory의 모든 동작을 포함하고 있고, 비슷하게 동자을 하도록 도와준다. 둘 모두 getBean() 메소드를 사용해서 Configuration을 위해 작성한 XML파일에서 정의한 Bean을 얻을 수 있다. 아까도 이야기 했지만, ApplicationContext Interface는 BeanFactory Interface의 확장이다.

ApplicationContext와 BeanFactory Interface간의 차이점은 Singleton 빈의 로딩하는 방법에 있다. BeanFatory는 getBean() 메소드가 호출될 때까지 Bean의 생성을 미룬다. 반면에 ApplicationContext는 Singleton 빈을 미리 로딩함으로 그 빈이 즉시 사용이 가능하도록 보장해 준다.

일반적인 테스트 코드를 작성할때는 두개의 차이가 거의 없을것이다. BeanFactory는 테스트 코드를 작성하기에 매우 유용하지만, 두 Interface의 차이를 알지 못하면, 이상하게 여길수도 있다. 최근에 Scheduler를 작성하게 되면서, 테스트 코드를 작성한 적이 있는데, Quertz의 Thread가 생성이 되어서 동작을 해야 하는데, 동작을 하지 않다가 getBean("scheduler")를 실행시켜줘야만 동작을 한는 것이었다. (BeanFactory 사용시)
그러나, ApplicationContext의 사용시는 ApplicatiionContext의 인스턴트가 생성되면, Quartz의 Thread가 실행되어 정해진 시간마다 Job을 실행하는 로그를 찍었다. 이유는 위에서 설명한 이유때문이다. (테스트시 ApplicationContext를 사용할 이유가 하나 늘었다.)

그리고 또하나 발견한 것은 getBean("beanId")을 통해 Bean의 reference를 얻어 올수 있다. 하지만, 가져온 Bean의 형이 내가 생각했던 것과는 다를 수도() 이는 Bean의 원 클래스에서 반환하는 오프젝트가 반환되기 때문이다.

[AbstractApplicationContext 코드 중에서]
public Object getBean(String name) throws BeansException {
  return getBeanFactory().getBean(name);

 }


만약, Factory 자체를 반환하기를 원한다면, "&"를 "beanId"앞에 붙여서 사용하면 된다.
이렇게 말이다. ==> getBean("&beanId)
이를 가르쳐 주면서 reference guide 를 잘 살 펴보라고 한다. 그래서 살펴보았더니. 딱 2줄에 걸쳐서 설명이 되어져 있다. Spring In Action에는 설명이 아예 안 되어 있다.

[BeanFactoryUtils코드 중에서]
public static boolean isFactoryDereference(String name) {
  return (name != null && name.startsWith(BeanFactory.FACTORY_BEAN_PREFIX));
 }

이 코드은 사실 AbstractBeanFactory 클래스에서 사용되는 메소드이다. 그리고
BeanFactory.FACTORY_BEAN_PREFIX 는 "&"로 정의되어 있다.