요즘 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 는 "&"로 정의되어 있다. 

어제는 Roby 세미나에 다녀왔다.
김 정현 책인 2시경에 오라고 해서, 12시부터 자기는 Ruby 투터리얼 강의가 있는데 루비를 알는 사람들은 2시부터 참석하면 된다고 했다. 조금 일찍 도착한 나는 별다방에서 시원하고 단 음료를 시켜놓고, 홀로 요즘 공부하고 있는 자바 소스를 분석하고 있었다.

이젠, 가야지하고 포스코 사거리로 나섰다. 그리고 세미나가 열리는 빌딩을 찾아 갔는데, 이게 왠걸? 느낌이 이상했다. 건물 1층의 보안 요원은 그런 행사가 없다고 하며, 혹시 다른 건물이 아니지 확인해 주었다. 나도 이상해서 전화를 해보았다.
앗 이럴수가 세미나 장소는 가락시장역에 있는 소프트웨어 진흥원 건물이었다. 그 곳은 이전에 Spring 세미나가 열렸던 곳이라 찾는 데는 어려움이 없었다. 하지만 왜 장소를 잘못 알았을까? 참 미스테이한 일이었지만, 이유를 찾는데는 어려움이 없었다. 행사, 세미나 게시판에서 전년도 행사장 위치 소개를 이번 행사 약도로 잘못 보고 헛걸음을 친 것이었다.

암튼 행사는 엄청 늦었다.

행사는 소프웨어 진흥원 건물 5층에서 열렸다. 약 100명 정도의 참석자들이 모여있었다. 나름 준비해온 세미나 자료를 참석자들에게 열정적인 모습으로 설명하는 모습이 이상적이었다. 하지만, 전문적인 Speaker들이 아니기에, 하고싶은 말을 전달하는 과정이 수월해 보이지는 았았다. 그러나 인상적인 것은 자기가 좋아하는 것을 더 많으 사람들에게 전하려는 열정많은 정말 뜨거웠다. 그리고, 제대로 준비해서 전달할 수 있는 기회가 곧 오지 않을까 생각이 들었다.
이 사람들의 열정과 젊음이 정말 부럽다.

몇몇 주제는 낯 설었지만, 흥미로왔다. 그리고 누구나 마지막까지 자리를 지치는 사람들에게만 주어진다는 상품 추첨 시간은 긴장감이 돌았다. 겨우 책 5권 밖에 되지 않아서, 5%의 확률.., 역시나 나는 추첨 운은 없다. 기존에 책을 가지고 있는 사람들이 당첨되어서 책을 포기해 주었지만, 나에게는 기회가 돌아오지 않았다.

세미나 주제중에 JRuby와 Spring Framework의 개발시 사용에 대한 발표가 있었다. 행사장에 많은 사람들은 자바로 개발을 해본 사람들이 많았고, 나역시 관심이 있는 주제이기도 했다. 왜냐하면, Rails의 생산성은 익히 알려져 있기 때문이다. 기기에다 자바 기술의 탄탄함까지 더해진다면이라는 가능성을 항상 염두에 두고 있기 때문에 Ruby와 Rails에도 관심을 가지고 있는 것이다.
세미나는 단순했다. "이렇게 이렇게 사용하면 되지 않을까요? 고객이 원하면 이렇게 하면 되지요" 라는 정도의 이해로 세미나를 진행한다는 것은 무리라는 생각이 들었다.
RubyOnRails의 입장에서 보면, 기존이 자바 Enterprise 기술은 경쟁자일 뿐이고, 극복하지 않으면, 커 나가지 못한다는 입장을 가지고, 타 기술에 대한 정확한 이해없이 융합 또는 양 기술의 동시 사용에 대해서 논하는 것은 시기 상조가 아닐까 싶었다.
정확하게는 Ruby라는 기술이 더 좋은데, 할 수 없이 자바를 사용해야 하는 것처럼 들렸다. (아니라면 정말 죄송)
나도 이야기를 들으면서, 그런데 왜 자바의 기술들을 쓰려고 할까라는 생각이 연신 들었다.
이에 대한 명확한 해답이 없으면, 아마도 한국에서 Ruby라는 기술의 확산은 그리 쉬운 길이 아닐것 같다. 결국 고객들을 설득해 나가야 한다. 고객이 원하는 것을 해 줄수 있다면, 루비든 자바든 다 같이 하나의 툴일 뿐이다.

그동안 많은 새로운 툴들이 나와서 개발자들이 편해질 거라고 했지만, 편해진 시간 만큼 개발자는 더 많은 일과 프로젝트를 하고 있을지도 모른다. 우리들의 Boss는 결코 멍청하지 않다. 고객은 개발시에는 무지하고 멍청해 보일지도 모르지만, 산출물이 나오는 시점에는 어는 누구보다도 예리하고 날카롭다. 그리고 천재적이기까지 하다. 항상 새로운 일들을 준비해 준다.
개발자들은 그러한 천재들을 상대하기 위해서 더 많은 공부와 자기가 습득한 기술들의 단련이 필요하고, 더불의 설득력을 길러야 할 것이다. 기대치 관리를 포함해서 말이다. (정말 두서 없이 글을 썼다.)

 
 

일주일에 한번씩, 점심(사제밥?)을 같이 먹는 김정현책임으로 부터 루비를 소개받고 책을 하나 사고, 루비를 알기 시작한 지가 벌써 6개월이 넘어간다. 하지만, 루비 자체의 언어적인 매력보다는 Rails라는 프레임워크가 주는 매력이 나에게 너무 크게 다가왔다. 아니 나뿐만이 아니라 루비라는 언어를 접하는 사람들에게 Rails는 확실한 Impact를 준다. 이미 인터넷에 많이 나돌고 있는 동영상과 www.rubyonrails.org 에 올라와 있는 동영상 강의는 무언가 해보고 싶은 욕구들을 이끌어 낸다.

지난 6개월 동안 짜본 프로그램이 처음 한달 공부하면서 짠 HTML에서 한글을 추출하고 다른 언어로 대체하는 프로그램이 전부라는 것이 부끄럽다.

하지만, Ruby와 Rails라는 것에 대한 관심은 지금 개발에 사용하고 있는 Spring Framework아 별반 다르지 않기 때문에 앞으로도 계속 관심을 갖을 것이다. 물론 ASP.NET의 MVC 프레임워크도 마찮가지로 내가 관심을 가지는 웹 기술들이다.

내일은 Roby관련 세미나가 있는 날이다. 이번에도 김정현 책임이 잊지않고 알려주었는데, 시간이 되면 꼭 가보고 싶다.