2016년 6월 28일 화요일

spring mvc의 exceptionHandler에서 mediaType 정보 획득하기

Spring MVC 를 사용하다보면 contentNegotiatingViewResolver 는 거의 필수 사용 설정이다.

따라서 exceptionHandler를 사용할 때에도 mediaType에 따라 응답 결과를 처리해야한다.

이 때 가장 많이 고민하게 되는 부분이 Spring Security를 사용하는 경우 응답처리였다.

json으로 요청한 경우는 로그인이 필요하다는 exceptionMessage를 내려보내주고 html로 요청한 경우 security에서 처리한 로그인 페이지로 가는 처리를 할 필요가 있다.

이를 위해서는

  1. 응답요청에 대한 MediaType
  2. method 에 설정한 @RequestMapping  타입의 produces의 MediaType
  3. controller 에 설정한 @RequestMapping 의 produces의 MediaType

이 두 가지에 대해 exceptionHandler에서 확인이 가능해야한다.

다음과 같이 확인이 가능하다.


2016년 6월 27일 월요일

request 별로 variable 관리하기

웹페이지를 구성하다 보면 페이지 별로 메뉴를 구성하고 싶은 경우가 많다.

thymeleaf 를 쓰는 경우 최상위 dom인 html에 th:with로 응답별로 변수를 선언해서 쓸 수 있지만 페이지가 많아질 수록 이렇게 관리하는 것에 한계가 있다.

이런 경우 페이지 별 변수를 따로 관리해주는 것이 좋다.


xml과 java object를 맵핑하지 않았다.

이렇게 하면 java의 기본 list, map으로 해당 object가 만들어지는데 오히려 이렇게 사용하는 게 관리하기 편하다.

아래와 같은 기능이 있다.

1. 모든 메뉴의 이름은 원하는 대로 지어도 된다. (예제엔 menuList안에 menu로 구성했지만 모두 제각각으로 지어도 된다.)
2. 하위 뎁스를 원하는 만큼 만들어서 사용이 가능하다.
3. 다만 url이란 선언 값은 꼭 있어야 한다.
4. 중첩되는 선언들은 지정한 url의 패스가 긴 것부터 변수들이 우선순위를 가지고 merge된다.
5. xml 수정시 새로고침 하지 않아도 된다.

간단하면서도 유용한 requset별 variable 구현이 아닐까 싶다.

2016년 6월 22일 수요일

Docker Beta 버전

Docker가 드디어 베타버전으로 올라섰다.

그동안 알파 버전으로 오랜 기간 머물렀었는데 이 기간동안 컨테이너 포트를 유지하지 않으면 매번 초기화되거나, 버전업할 때마다 컨테이너 정보가 날아가고 호환이 안되는 등의 문제가 있었지만 나름 알차게 쓴 것 같다.

알파 버전을 떼고 나온 베타버전에는 큰 변화가 있다.

가장 큰 변화는 docker toolbox를 버렸다는 점이다.

docker toolbox는 각 os에 맞게 vm을 띄우기 위해 제공되었는데 virtual box를 설치하고 해당 virtual box에 core os를 올리는 등의 작업을 해주었다.

즉, 그동안 virtual box에 종속된 편의성의 toolbox를 제공하였는데 베타 버전 이후는 Mac, Windows는 각각의 OS에서 구현된 vm 방식을 사용하여 virtual box에 대한 종속성에서 벗어나게 되었다.

mac은 xhyve, windows는 Microsoft Hyper-V를 이용해 docker의 사용이 가능해졌다.

window의 경우 사용시 한가지 놓치면 안되는 설정이 있다.


위의 설정에서 experimental의 port 노출 설정이다.

아직 베타 버전이라 그런지 아니면 좀더 자세히 알지 못해서 그런지 몰라도 window에서 hyper-v를 통해 띄운 컨테이너를 로컬에서 접근하려면 저 설정을 해주어야 하더라..


그리고 kitematic의 응답이 느리고 변경점에 대한 반응이 바로바로 적용되지 않는 문제가 현재 보인다. (컨테이너를 중지해도 상태가 표시되지 않거나 콘솔이 이전 콘솔이 계속 보이는 현상 등..)

베타버전도 어서 빨리 개선이 되어 좀더 쾌적한 환경에서 사용을 할 수 있었으면 좋겠다.

2016년 6월 20일 월요일

Spring Boot war에서 MyBatis 사용시 TypeHandler scan 오류가 발생하는 현상

1번과 같이 typeHandler scan 범위를 지정하면 local eclipse에서는 동작하지만 spring boot war를 빌드한 후  호출하면 올바르게 동작하지 않는 현상이 있다.



이 경우 2번과 같이 일일이 typeHandler를 지정하여 해결할 수도 있다.

mybatis에서는 spring boot 사용시 war에 묶인 path가 /WEB-INF/lib에 묶여 올바른 패스가 인식 되지않는 경우를 위해 SpringBoot용 VFS를 제공한다.

3-1과 같이 mybatis-spring-boot-starter를 참조한 후 3-2와 같이 SpringBootVFS를 설정하면 spring boot에서 mybatis scan 설정이 올바르게 동작한다.

(참고 링크)




해당 문제는 mybatis가 버전업하면서 해결된 듯 하다.

MyBatis Java 8 관련 TypeHandler 설정 불필요