Root Application Context와 Servlet Context

Spring에서 Transaction 설정을 하였으나 제대로 동작되지 않아 원인을 찾던 중

Root Application Context와 Servlet Context 개념을 알게 되었고,

Servlet Context에도 Service, Dao Bean 들을 중복으로 등록한 것이 문제가 된 것임을 알게 되었다.

Root Application Context와 Servlet Context에 대해 잘 정리되어 있는 글을 찾아서 남겨 놓는다.

출처 : http://www.mungchung.com/xe/spring/21220

---

IoC 컨테이너는 Root Application Context와 Servlet Context 2가지 방법으로 만들수 있다.
스프링 샘플프로젝트를 만든 후에 web.xml을 보면 아래와 같이 나뉘어 있다.

 

 

 

Root Application Context
  - 전체 계층구조에서 최상단에 위치한 컨텍스트
  - 서로 다른 서블릿 컨텍스트에서 공유해야하는 Bean들을 등록해놓고 사용할 수 있다.
  - 웹 어플리케이션 전체에 적용가능한 DB 연결, 로깅기능등에 이용
  - Servlet Context에 등록된 Bean 이용 불가능!
  - Servlet Context와 동일한 Bean이 있을 경우 Servlet Context Bean이 우선된다.
  - 하나의 컨텍스트에 정의된 AOP 설정은 다른 컨텍스트의 빈에는 영향을 미치지 않는다.

 

Servlet Context
  - 서블릿에서만 이용되는 컨텍스트
  - 타 서블릿과 공유하기 위한 Bean들은 루트 웹 어플리케이션 컨텍스트에 등록해놓고 사용해야 한다
  - DispatcherServlet은 자신만의 컨텍스트를 생성,초기화하고
    동시에 루트 어플리케이션 컨텍스트를 찾아서 자신의 부모 컨텍스트로 사용

 

프로젝트시에 IoC 컨테이너 구성방법은 아래와 같이 여러가지를 사용할 수 있다.
1) 루트 어플리케이션 컨텍스트만 이용
2) 서블릿 컨텍스트만 이용
3) 루트어플리케이션 컨텍스트와 서블릿 컨텍스트 하나씩 이용 (가장 많이 사용하는 설정인듯)
4) 루트어플리케이션 컨텍스트 하나에 서블릿 컨텍스트 여러개 이용

 

IoC컨테이너를 루트 컨텍스트든, 서블릿컨텍스트든 하나만 사용해도 되는데 굳이 구조화해서 나누는 이유는
전체 어플리케이션을 좀 더 구조화하기 위함이라고 한다 (-_-)

 

 

이글을 적는이유는 Bean등록을 어디에(루트 컨텍스트냐? 서블릿 컨텍스트냐?) 하느냐에 따라서

Bean이 DI 되고 안되고 차이가 있는것 같아서(경험상...그렇다. 아직 잘 몰라서 아닐수도 있고 -_-) 확인차 적는것이다.

 

 

참고글들 읽어보기

* http://code.google.com/p/developerhaus/wiki/TobySpring_10

* http://nangchang.nes.or.kr/?page=1

* http://whiteship.me/?p=12192

* http://toby.epril.com/?p=934

 

**********************************************************************

2012/6/13 내용 추가함

 

검색하다보니 Root Application Context와 Servlet Context 설정시 도움이 될만한 정보가 있어서 퍼온다.

출처는 http://bumsgy-innori.tistory.com/tag/%EC%8A%A4%ED%94%84%EB%A7%812.5%EC%84%A4%EC%A0%95

이곳인데 이곳 쥔장도 퍼온글인것 같다.

**********************************************************************

 

 

SpringMVC를 이용한 개발에서 Controller류는 xxx-servlet.xml에 그 외의 Service, Dao류는 applicationContext*.xml에 등록해야 합니다. 직접 등록이 아닌 Scanner을 사용할 경우 중복하지 않도록 해야 합니다. 따라서 처음 만드신 것처럼 xxx-servlet.xml에서 모든 Stereotype 빈을 모두 다 검색하는 component-scan 설정은 잘못됐습니다.

 

이 원칙만 잘 준수하시면 아무 문제없을 것입니다.

 

이번엔 좀 복잡하게 설명해보죠.

 

세가지 사용하신 stereotype이 있습니다. @Repository, @Service, @Controller죠.

 

제가 이전에 작성한 viewtopic.php?f=5&t=20#p33 을 읽어보시면 잘 설명이 되어있는 내용이 있습니다. 일반 applicationContext*.xml에 설정한 내용과 xxx-servlet.xml에 설정한 내용은 두개의 다른 ApplicationContext(이하 AC)로 만들어지고 xxx-servlet.xml의 AC는 applicationContext*.xml에 의해서 만들어진 AC의 child context로 등록이 됩니다.

 

상위 AC를 ac, 웹에서 정의된 AC를 web-ac라고 불러보죠.
 
원래 하신 설정에 따르면 ac에서는 controller,form류(@Controller)를 제외한 나머지만 scan하도록 되어있습니다. 따라서 @Repostiory, @Service가 붙은 bean들이 등록이 되겠죠.

 

web-ac는 exclude조건없이 full-scan을 했습니다. 따라서 @Repository, @Service, @Controller가 붙은 빈들이 다 등록이 됐죠.

 

그리고 ac와 web-ac가 상-하위 ac관계를 가집니다. 이때 같은 bean이 두번 등록되도 문제는 없습니다. 하위 context에서는 상위 context에 등록된 bean을 override합니다. 하위 context에서 먼저 bean을 찾고, 없으면 그때 상위를 찾기 때문에 override한 것과 마찬가지입니다.

 

따라서
ac - @Service, @Repository
web-ac - @Service, @Repository, @Controller

이렇게 각각 빈들을 가지고 있는 상태입니다.

 

스프링이 transaction을 적용하는 방법은 AOP를 이용해서 해당 빈의 proxy를 만들어서 tx가 적용되는 bean을 바꿔치기 하는 방법을 이용합니다. 그러면 원래 @Service(@Transactional)이 붙은 빈은 뒤로 숨고 tx가 적용된 proxy bean이 @Service가 붙은 bean으로 대치됩니다. tx설정은 ac에만 되어있기 때문에 이 것이 적용되면

 

ac - tx적용(@Service), @Repository
web-ac - @Service, @Repository, @Controller

 

이런 형태가 됩니다.

web-ac쪽은 tx가 적용되지 않은 @Service가 그대로 남아있습니다.

 

그리고 @Controller가 동작하고 여기에 @Autowired를 걸면, 우선 같은 context에서 검색을 합니다. 여기서도 @Service가 지정된 같은 bean이 등록되어있기 때문에 web-ac에 등록된 @Service bean을 사용합니다. 하지만 이 bean은 tx를 위한 proxy bean이 아니기 때문에 tx가 동작하지 않습니다. 따라서 처음과 같은 문제가 발생합니다.

 

다음은 @Service를 떼고 <bean>으로 등록하니 tx가 적용된 상황을 살펴보죠.
이때는 @Service에 의해서 scan되지는 않고 bean에 의해서 명시적으로 service bean이 등록됩니다. 물론 <bean>을 등록한 ac에서만 되겠죠. web-ac에서는 full-scan을 하지만, @Service가 없기 때문에 등록되지 않습니다.

 

ac - Service, @Repository
web-ac - @Repository, @Controller

 

이런 상황이 되는거죠.

여기에 tx설정이 적용되면 @Transactional이 붙은 것을 ac 내에서 찾아서 적용하므로

 

ac - tx적용(Service), @Repository
web-ac - @Repository, @Controller

이런 구조가 됩니다.

 

이제 Controller가 @Autowired에 의해서 service를 찾으면 이때는 ac에 등록된 tx적용(Service) 빈이 호출됩니다. 그러니 당연히 tx가 먹겠죠.

따라서 앞에서 하신 모든 가정들(@Service, @Transactional은 같이 쓰면 안된다, 인터페이스에 적용을 안해서 그렇다거나.. 기타등등)은 다 틀렸습니다.

마지막으로 제가 알려드린대로 하시면

 

ac - tx적용(@Service), @Repository
web-ac -@Controller

 

이렇게 깔끔하게 설정되겠죠.

 

Web을 사용하는 스프링 애플리케이션의 설정의 기본원칙만 지키시면 아무 문제가 없는 것입니다. 보통 component-scan을 사용하면 exclude, include등을 잘 적용하지 못해서 이런 문제가 발생할 수 있습니다. 편리한만큼 신경쓸 것도 있는거죠.

 

그리고 exclude 하실때 이름을 가지고 regex를 적용하셨는데 그보다는 annotation filter을 이용하시는 것이 더 깔끔할 것 같습니다. 아예 web쪽과 나머지를 root경로부터 분리하면 간단하긴 하지만, 보통 모듈별로 몰아두기 때문에 annotation 방식이 편합니다.

제가 사용하는 방법은

ac쪽은

 web-ac쪽은

 입니다.