정말 없다.

스프링의 엔진이자 핵심인 IoC컨테이너, 또는 애플리케이션 컨텍스트에는 전용 설정파일이라는 것이 아예 존재하지 않는다.  그렇다고 스프링 컨테이너는 디폴트 설정 외에는 세밀하게 제어 하거나 기능을 확장하거나 조작하는 것이 불가능한 것은 아니다. 스프링 컨테이너만큼 유연하게 그 동작을 변경하고 확장할 수 있는 컨테이너는 지금까지 본 적이 없다.

XML 대신 애노테이션을 이용한 설정을 자랑하는 다른 많은 프레임워크에도 대부분 적지 않은 XML 설정파일이 존재한다. DS 설정, 컴포넌트 설정, 페이지설정, 리모팅, WS 등등 각종 프레임워크 런타임이 제공하는 서비스에 대한 설정은 외부에서 각각의 전용 XML로 만들어줘야 한다. 단지 개발자가 만드는 앱 코드가 담긴 클래스 정도만 XML 등록 없이 애노테이션으로 치장했을 뿐이다.

하지만 스프링은 그렇지 않다. 스프링은 DI라는 핵심 가치를 자기 자신에게도 엄격하게 적용하고 있고, 그 덕분에 컨테이너 자신이 DI가 가져다 주는 모든 장점을 최대한 누리고 있는 것이다. DI의 핵심은 무엇인가? 결국 따지고 들어가보면 그 핵심은 개방폐쇄원칙(OCP)이라고 불리는 객체지향설계원칙이나 낮은 결합도 높은 응집도로 표현되는 소프트웨어 개발의 근본적인 원칙을 충실히 따르는 것이다. 그로 인해서 유연한 확장과 편리한 재사용이라는 OO의 혜택을 개발자들이 손쉽게 얻도록 만들어주는 것이다. 표준이라는 이름 하에 자바언어와 OO의 가치를 훼손 시켰던 예전의 EJB 기술에 대한 반성으로 출발해서 다시 자바의 근본으로 돌아가서 그에 충실하도록 돕는 것이 스프링이다.

생각해보자.

컨테이너의 어떤 확장기능 또는 옵션을 XML이라는 별도의 DSL로 만들어서 그것을 읽어 해석해서 그것을 가지고 if로 점철된 조건판단으로 넘기는 것이 OO적이라고 할 수 있을까? 그보다는 전략에 따라 바뀔 수 있는 확장가능한 부분을 객체합성으로 분리하고 인터페이스를 두어 구현에서 독립시키고 그 구현 오브젝트는 언제든지 외부에서 결정해서 주입할 수 있도록 만들고 하고 그 확장 구현 오브젝트를 통해서 확장기능, 옵션 등을 제공하는 것이 OO다운 것이 아닐까?

스프링은 컨테이너의 모든 확장포인트에 해당하는 부분을 DI 를 통해서 주입 받도록 만들었다. 애플리케이션 컨텍스트는 수십여가지의 옵션 포인트, 확장기능 포인트 들을 제공한다. 어떤 이들이 엉터리 비난을 하는 것처럼 스프링은 XML에 종속적이지 않다. 단 한번도 XML에 종속된 적이 없다. 스프링은 BeanDefinition이라는 인터페이스를 통해서 하나의 빈에 대한 메타데이터를 제공받아 사용한다. 이를 생성해주는 것은 BeanDefinitionReader 인터페이스를 구현한 어떤 구체적인 전략이다. 그 중에서 XmlBeanDefinitionReader를 사용하면 XML문서로부터 빈 메타정보를 담은 BeanDefinition 오브젝트의 변경이 일어나는 것 뿐이다. 그것을 PropertiesBeanDefinitionReader로 바꿔도 아무 상관없다.  단지 XML로 빈 메타정보를 표현하는 것이 많이 쓰였던 것 뿐이다. Java5+환경이 많아지고 애노테이션의 사용에 대한 거부감이 줄어들면서 빈 정보를 애노테이션에서 가져오는 간단한 "전략"하나를 추가했을 뿐이다. 스프링이 애노테이션을 사용하기 시작했다고 그 컨테이너의 기존 코드에 변경이 있었는가? 전혀 없었다. 스프링은 변경에는 완벽하게 닫혀있으면서 무한한 확장에는 열려있는 OCP 원칙을 충실히 잘 지키고 있기 때문에 가능한 일이다.

스프링 컨테이너의 모든 설정은 DI로 이루어진다. 스프링의 applicationContext.xml 파일은 컨테이너 설정 파일이 아니라 스프링이 관리하는 빈을 정의한 빈 메타정보 파일일 뿐이다. 스프링 컨테이너는 그 빈을 만드는 입장이긴 하지만 스스로 자신이 만드는 빈을 DI하는 대상으로 삼는다. 따라서 스프링 컨테이너의 설정을 만들고 싶다면 스프링 컨테이너의 확장 인터페이스를 구현한 새로운 전략을 하나 만들어서 빈으로 등록하면 된다. 그 확장 기능이 더 세분화 된다면 다시 쪼개서 더 많은 DI 구조로 만들어도 상관없다.

AutoProxyCreator는 스프링 컨테이너의 확장포인트인 BeanPostProcessor의 구현이다. 따라서 이 빈이 등록되면 스프링 컨테이너가 이 타입의 빈을 DI 받기 때문에 컨테이너의 확장기능으로 동작한다. 자동 프록시 생성기능은 AOP의 핵심 엔진이다. 조건에 맞는 빈을 찾아서 자동으로 ProxyFactoryBean을 추가해주기 때문이다. 단순히 빈 이름을 가지고 AOP 대상을 찾는 것이 아니라면 빈을 찾는 부분을 다시 새로운 확장포인트로 만들고 이를 DI를 통해서 확장하게 하면 된다. 그것이 AdvisorAutoProxyCreator이다. Advisor를 그 확장 포인트로 하는 AutoProxyCreator이다. 만약 AspectJ 포인트컷 표현식을 사용하고 싶다면 Advisor의 DI포인트인 Pointcut의 구현으로 DI될 AspectJExpressionPointcut을 역시 빈으로 등록하기만 하면 된다. 스프링 컨테이너->AdvisorAutoProxyCreator->AspectJExpressionPointcut 와 같은 DI관계가 만들어지면서 스프링 컨테이너의 확장은 또 OO의 장점을 살려 유연하게 변경될 수 있다.

그래서 결국 스프링에는 컨테이너의 설정파일이 없다. 단지 DI를 위한 빈 설정 메타정보를 담은 특정 BeanDefinitionReader 구현에 맞는 파일만 있을 뿐이다. 그리고 그것으로 충분하다.

 

자신이 강조하는 핵심가치를 스스로 먼저 충실히 지키고 있다는 것이 내가 스프링을 좋아하는 이유이다. 마찬가지 이유로 스스로 TDD로 개발된 JUnit을 좋아하는 것이다. DI를 주장하고 TDD를 얘기하려면 그 쯤은 스스로 모범을 보여야 하지 않을까?

 

비슷한 이유로.. 테스트를 위해 만들어진 프레임워크면서 스스로는 testability가 떨어지는 TestNG는 우습게 보이기도 한다.

Related posts:

  1. Spring 3.0 (59) 프로퍼티 파일 이용하기 – placeholder vs SpEL
  2. 톰캣 앞에 아파치 웹 서버(Httpd)를 두어야 할까?
  3. Maven archetype 설정파일 자동생성기 – ArchetypeXmlWriter
  4. 파이썬 완벽 가이드 전자책

Facebook comments:

to “스프링 컨테이너에는 설정파일이 없다”

  1. Click Here
    [url=http://bootsforwomenoutlet.com]uggs on sale for women[/url]
    uggs on sale for women

  2. womens adidas running shoes 스프링 컨테이너에는 설정파일이 없다 » Toby’s Epril

  3. Sneak A Peek At THIS Site

  4. thanks for share!

  5. discount keen shoes sale 스프링 컨테이너에는 설정파일이 없다 » Toby’s Epril

  6. thank you for share!

  7. walking shoes 스프링 컨테이너에는 설정파일이 없다 » Toby’s Epril

  8. mbt kisumu 스프링 컨테이너에는 설정파일이 없다 » Toby’s Epril

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha