SW-PRODUCT/개발-웹닭·HTTP

Spring validation - 2. @RequestBody

굴돌 2014. 12. 24. 18:52


어제 글(http://blog.daum.net/rollin/8097071)에 이어서...


어제 글쓸때 controller에서 statusCode를 일일이 세팅하도록 해두고 보니...

controller에서 자꾸 statusCode 세팅하는게 참 보기 싫었다.


그래서 이래저래 알아봤는데

예전에 쓰던 HandlerExceptionResolver 처리하는 방식으로는 viewResolver 지정하는 부분이 매끄럽게 처리되질 않았다.


json/xml 사이를 자유롭게 오갈 수 있게 하거나

viewResolver가 교체되더라도 잘 처리될 수 있도록하기 위해서

@ControllerAdvice 꼬리표와 ResponseEntityExceptionHandler 클래스를 확장해서 쓰는 방법으로 전략을 바꿨다.

ㄴ 참고: http://springinpractice.com/2013/10/09/generating-json-error-object-responses-with-spring-web-mvc


@RequestBody 사용할 경우 기존의 BindingException이 아니라 MethodArgumentNotValidException 예외가 발생하는것 때문에...그리고 MessageConverter가 사용되는 부분 때문에 기존 dispatcherServlet 구조에서 떨어져나와 따로 도는것 아닌가 싶었는데

뭐 결국은 기존 구조에서 방식만 살짝 바뀐 듯 싶다.


여전히 hander 처리해서 modelAndView를 얻어내는데 이때 exception이 발생하면 exception 처리하는 block이 돌게 된다.


다만, 3.2인가?에서 추가된 ResponseEntity를 이용하게 되면 status 지정, header에 contentType 지정해서 view resolver를 자동으로 선택하게 하는 부분, body의 model 지정하는 것 다 잘 풀리기 때문에 어쨌든 @ControllerAdvice 방식으로 처리함.


흠... 역시 프레임워크 건드리면 어디선가 문제가 생긴다.

@ControllerAdvisor 형태로 예외를 처리한 경우 MessageConverter를 이용해서 결과를 rendering한다.

그런데..message convert 목적때문인지 구조때문인지 HTML로 처리해주는 기능..특히 velocity 등을 쓰는 기능은 기본적으로는 없다.


Spring 기능중에 bindingResult를 HTML element에 잘 엮어주는 기능이 있는데 이것과 연동시키려면 괜히 건드리는 것보다 필요할때 Spring 바인딩 기능을 세팅하는게 나을 것 같아서 이 상태로 일단 멈춤.


결론은... REST 타입에 대해서는 @Validated 처리가 잘 되는데 HTML은 안되고 있음..;;