Spring 3.0 (47) PropertyEditor vs ConversionService

스프링에는 두 가지 대표적인 TypeConverter가 존재한다.

하나는 SpringMVC가 HttpRequest를 커맨드(모델)로 전환할 때 사용하는 (Web)DataBinder이고, 다른 하나는 스프링의 빈의 프로퍼티 설정을 위해서 사용하는 BeanWrapper이다. 두가지 모두 TypeConverter 인터페이스를 구현하고 있다.

두 경우 모두 타입전환이 필요로 하는 이유는 텍스트 포맷으로 존재하는 XML설정이나 HTTP 파라미터를 임의의 오브젝트로 전환해야 하기 때문이다.

스프링이 이 타입변환을 위해서 사용하는 방법은 JavaBeans의 PropertyEditor이다. 각각 PropertyEditorRegistry가 되어서 기본타입을 포함해서 Class, Resource 나 콜렉션 같은 복잡한 타입도 간단하게 변환이 가능하도록 만들고 있다. 또한 새로운 Editor를 추가하는 것도 어려운 일이 아니다. SpringMVC를 마스터하기 위해서(@MVC도 마찬가지이다) 중요한 것이 이 PropertyEditor와 DataBinder 메카니즘이다.

이 PropertyEditor는 한가지 큰 약점이 있다. 그것은 쓰레드쎄이프하지 않다는 것이다. 아주 잠깐이지만 인스턴스 변수 안에 value를 저장해 두고 그것을 다시 읽어오도록 되어있다. 원래 GUI툴에서 프로퍼티 뷰와 실제 오브젝트의 프로퍼티의 값을 전환하기 위해서 설계한 것이기 때문에 구지 쓰레드쎄이프하게 만들어지지 않은 것이다.

따라서 모든 PropertyEditor는 순차적으로 사용되는 것이 보장되지 않는다면 반드시 쓰레드마다 새 인스턴스를 만들어서 써야 한다. initBinder 등에서 에디터를 등록할 때 new로 새로운 인스턴스를 만드는 것이 필수다.

문제는 M2O관계에서 아이디-엔티티 변환을 시도하는 경우다. 폼에는 레퍼런스 아이디가 넘어가고 돌아오면 그 아이디에 해당하는 실제 오브젝트를 DB(또는 캐쉬)에서 가져오는 것이다. 이 방법의 문제점은 DAO등을 PropertyEditor가 DI 받아야 하므로 빈으로 등록해야 한다는 점이다. 문제는 싱글톤 빈으로 등록되면 멀티쓰레드에서 문제가 발생할 수 밖에 없다. 그래서 프로토타입 빈으로 등록하고 이를 메소드 주입 등의 방법을 이용해서 매번 새 인스턴스를 가져오게 만들어야 한다.

이를 지키지 않고 싱글톤으로 그냥 썼을 때는 치명적인 버그를 심을 수 있다. 대부분 잘 되다가 사용자가 급격히 늘어나면 갑자기 엉뚱한 데이터가 들어가거나 나오는 일이 생길 수 있다.

하지만 PropertyEditor가 쓰레드쎄이프하지 않다는 것을 모르는 스프링 개발자들이 적지 않다. 자바의 java.text.Format 클래스들이 쓰레드쎄이프 하지 않다는 것을 모르는 것과 비슷하다.

그래서 스프링은 3.0에서 PropertyEditor를 대체할 수 있는 새로운 타입변환 방식을 도입했다. 바로 ConversionService이다. 이 ConversionService는 쓰레드 쎄이프한 임의의 타입변환을 지원한다. 따라서 PropertyEditor처럼 싱글톤으로 등록하고 사용하는 것에 대한 제한이 없다.

이 컨버전 서비스는 ConfigurablePropertyAccessor에 지원메소드가 추가되었다. 이제 BeanWrapper는 ConversionService를 PropertyEditor와 함께 사용할 수 있다. PropertyEditor를 완전히 대체할 것인지, 일단은 보조적으로 사용하게 하고 차차 전환할 것인지는 확실치 않다. 아마도 후자가 아닐까 싶다.

지난 몇주간 키쓰 도날드가 열심히 이 ConversionService를 코어에 추가하는 작업을 해왔다. 이제 95학번 유겐 횔러가 이를 스프링 전체에 적용하는 작업을 진행할 것이다.  01~03년 사이에 개발되었던 pre-1.0에 존재했던 오래된 스프링의 기본 메카니즘에 대대적인 개선이 일어나는 것을 보는 것은 즐거운 일이다.