pageImpl 로 반환된 json 타입 restTemplate 호출하기

data jpa를 쓰는 경우 응답 처리의 paging 처리를 하기 위해 pageImpl로 반환하는 경우가 많다.
이 결과를 restTemplate으로 호출하는 경우 pageImpl 으로 반환하는 방법은 다음과 같다.
pageImpl을 재선언하여 restTemplate 호출을 받을 수 있는 class를 만든다.
아래는 단순 map 형태로 반환 받는 pageImpl의 구현 예이다.

@JsonIgnoreProperties(ignoreUnknown = true)
public class RestPageImpl extends PageImpl<Map<?, ?>> {
 private static final long serialVersionUID = 1L;

 @JsonCreator(mode = JsonCreator.Mode.PROPERTIES)
 public RestPageImpl(@JsonProperty("content") List<Map<?, ?>> content, @JsonProperty("number") int page,
   @JsonProperty("size") int size, @JsonProperty("totalElements") long total) {
  super(content, new PageRequest(page, size), total);
 }

 public RestPageImpl(List<Map<?, ?>> content, Pageable pageable, long total) {
  super(content, pageable, total);
 }

 public RestPageImpl(List> content) {
  super(content);
 }

 @SuppressWarnings("unchecked")
 public RestPageImpl() {
  super(Collections.EMPTY_LIST);
 }
}

ModelAttribute에 대해 annotation 적용하기

이전에 [annotation을 사용한 controller aop 설정하기] 란 글을 쓴 적이 있다.

class 나 method 단위에서 aop를 적용하는 방법에 대한 내용인데 parameter 단위로 aop를 적용을 할 수도 있다.

하지만 개인적으로 느끼기엔 parameter 단위의 aop적용은 그리 효율적이지 못하다.

aop 문법이 특정 타입에 대해 적용되어 있는 annotation을 적용하는 것에 대해 효과적인 명시 방법이 없다.

method parameter의 첫번째가 특정 조건일때, 끝이 특정 족건일 때, 중간에 특정 조건일 때 처럼만 선언이 가능하여 어색하고 딱히 확실한 명시 방법이 없다.
(혹 내가 못찾은 것 일 수도 있겠지만..)


또 하나의 문제는 spring의 ModelAttribute처럼 request parameter나 path variable에 대해 바인딩을 하려면 aop를 통한 처리는 복잡하고 어렵다.


이에 대해 Spring은 HandlerMethodArgumentResolver 기능을 제공한다.

넘어오는 매개 변수에 대해 supportsParameter 인 경우 응답값을 resolveArgument 메소드를 통해 전달해 줄 수 있다.


하지만 해당 구현만 하면 2가지 단점이 있다.

1. 외부에서 넘어온 request parmaeter나 path variable의 값이 object 에 맵핑되지 않는다. (modelAttribute 기능이 적용되지 않는다.)
2. hibernate validation 체크가 무시 된다.

따라서 스프링이 modelAttribute에 대해 어떻게 동작하는지를 살펴보는 것이 좋다.

스프링에서는 HandlerMethodArgumentResolver을 modelAttribute에 대해서 구현한 ModelAttributeMethodProcessor를 제공하며 특히 servlet을 사용하는 경우 ModelAttributeMethodProcessor를 확장한 ServletModelAttributeMethodProcessor를 제공한다.

ModelAttributeMethodProcessor는 resolveArgument 메소드가 final 선언 되어 있어 커스텀한 확장을 하지 못한다.


따라서 다음처럼 custom ModelAttributeMethodProcessor를 만들어준다.

public abstract class BlueskyHandlerMethodArgumentResolver implements HandlerMethodArgumentResolver {
 
 /* (s) ServletModelAttributeMethodProcessor method copy */
 @Override
 public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer,
   NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
  String name = ModelFactory.getNameForParameter(parameter);
  Object attribute = (mavContainer.containsAttribute(name) ? mavContainer.getModel().get(name) :
    createAttribute(name, parameter, binderFactory, webRequest));

  if (!mavContainer.isBindingDisabled(name)) {
   ModelAttribute ann = parameter.getParameterAnnotation(ModelAttribute.class);
   if (ann != null && !ann.binding()) {
    mavContainer.setBindingDisabled(name);
   }
  }

  WebDataBinder binder = binderFactory.createBinder(webRequest, attribute, name);
  if (binder.getTarget() != null) {
   if (!mavContainer.isBindingDisabled(name)) {
    bindRequestParameters(binder, webRequest);
   }
   validateIfApplicable(binder, parameter);
   if (binder.getBindingResult().hasErrors() && isBindExceptionRequired(binder, parameter)) {
    throw new BindException(binder.getBindingResult());
   }
  }

  // Add resolved attribute and BindingResult at the end of the model
  Map<string, object> bindingResultModel = binder.getBindingResult().getModel();
  mavContainer.removeAttributes(bindingResultModel);
  mavContainer.addAllAttributes(bindingResultModel);

  return binder.convertIfNecessary(binder.getTarget(), parameter.getParameterType(), parameter);
 }

 protected Object createAttribute(String attributeName, MethodParameter methodParam,
   WebDataBinderFactory binderFactory, NativeWebRequest request) throws Exception {

  return BeanUtils.instantiateClass(methodParam.getParameterType());
 }
 
 protected void bindRequestParameters(WebDataBinder binder, NativeWebRequest request) {
  ServletRequest servletRequest = request.getNativeRequest(ServletRequest.class);
  ServletRequestDataBinder servletBinder = (ServletRequestDataBinder) binder;
  servletBinder.bind(servletRequest);
 }
 
 protected void validateIfApplicable(WebDataBinder binder, MethodParameter methodParam) {
  Annotation[] annotations = methodParam.getParameterAnnotations();
  for (Annotation ann : annotations) {
   Validated validatedAnn = AnnotationUtils.getAnnotation(ann, Validated.class);
   if (validatedAnn != null || ann.annotationType().getSimpleName().startsWith("Valid")) {
    Object hints = (validatedAnn != null ? validatedAnn.value() : AnnotationUtils.getValue(ann));
    Object[] validationHints = (hints instanceof Object[] ? (Object[]) hints : new Object[] {hints});
    binder.validate(validationHints);
    break;
   }
  }
 }
 
 protected boolean isBindExceptionRequired(WebDataBinder binder, MethodParameter methodParam) {
  int i = methodParam.getParameterIndex();
  Class<?>[] paramTypes = methodParam.getMethod().getParameterTypes();
  boolean hasBindingResult = (paramTypes.length > (i + 1) && Errors.class.isAssignableFrom(paramTypes[i + 1]));
  return !hasBindingResult;
 }
 /* (e) ServletModelAttributeMethodProcessor method copy */
}

이제 custom한 annotation을 만들어 본다.

/**
 * 로그인한 유저의 Blog 정보를 주입하기 위해 사용하는 aop
 * @author bluesky
 *
 */
@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface UserBlog {

 public boolean checkBlog() default false; // 외부 접근 파라메터에 대해 유저의 blog 인지 확인 여부
}

해당 어노테이션이 적용된 modelAttribute에 대한 methodArgumentResolver를 만들어준다.

/**
 * 유저의 Blog 정보를 반환하는 Resolver
 * @author bluesky
 *
 */
public class UserBlogHandlerMethodArgumentResolver extends BlueskyHandlerMethodArgumentResolver {

 @Override
 public boolean supportsParameter(MethodParameter parameter) {
  return Blog.class.isAssignableFrom(parameter.getParameterType()) && Arrays.asList(parameter.getParameterAnnotations()).stream().anyMatch(annotation -> annotation.annotationType().isAssignableFrom(UserBlog.class));
 }

 @Override
 public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
  List<Blog> userBlogList = BlogRequestAttributeUtil.getUserBlogList();
  if (userBlogList.isEmpty()) {
   throw new BlueskyException(BlogErrorCode.NOT_EXIST_BLOG);
  }
  
  Blog requestBlog = (Blog) super.resolveArgument(parameter, mavContainer, webRequest, binderFactory);
  
  UserBlog userBlog = (UserBlog) Arrays.asList(parameter.getParameterAnnotations()).stream().filter(annotation -> annotation.annotationType().isAssignableFrom(UserBlog.class)).findAny().get();
  if (userBlog.checkBlog()) {
   
   if (requestBlog.getId() == 0) {
    throw new BlueskyException(BlogErrorCode.NOT_EXIST_PARAMETER_BLOG_ID);
   }
   return userBlogList.stream().filter(blog -> blog.getId() == requestBlog.getId()).findAny().orElseThrow(() -> new BlueskyException(BlogErrorCode.INVALID_PARAMETER_BLOG_ID)); // 유저의 블로그가 아닌 접근인 경우 에러
  }
  
  return userBlogList.get(0);
 }
 
}

이제 해당 annotation 을 사용하면 modelAttribute가 동작하고 hibernate validation도 처리가 되는 custom methodArgumentResolver가 동작하는 것을 확인 할 수 있다.

 @PreAuthorize(AuthorizeRole.PRE_AUTHORIZE_ROLE)
 @GetMapping(value = "/{id}/article/write")
 public String writePage(@UserBlog(checkBlog = true) Blog blog, ModelMap modelMap) {
  modelMap.addAttribute(articleCategoryService.findByBlog(blog));
  return "blog/write";
 }

Spring Boot 1.4.x 에서 Thymeleaf 3 사용하기

Spring boot 1.4.0.RELEASE 이후 Thymeleaf 3.0을 지원하게 되었다.

기존 프로젝트를 판올림하면서 기록해본다.

1.4.x 이후에도 Spring Boot는 Thymeleaf 2에 대해 default 선언을 하고 있다.

Spring Boot Docs에는 다음과 같이 Thymeleaf 3 적용방법을 안내하고 있다.

[Use Thymeleaf 3]


이 내용은 기본적으로 사용하는 Thymeleaf 3이 적용에 대해서 안내하고 있으며 추가적인 라이브러리 들에 대해서는 언급되어 있지 않다.

다음과 같이 pom.xml에 추가한다.

<properties>
    <thymeleaf.version>3.0.0.RELEASE</thymeleaf.version>
    <thymeleaf-layout-dialect.version>2.0.0</thymeleaf-layout-dialect.version>
</dependency>

기본으로 사용하는 thymeleaf-layout-direct의 경우 boot dependencies에는 1.x대 (thymeleaf 2이하 지원)으로 선언되어 있으나 위 선언을 하면 2.x대 (thymeleaf 3 지원)으로 버전 상속된다.

추가적으로 사용하는 라이브러리에 대해 다음가 같이 추가해주어야 한다.

Java 8을 사용하는 경우 thymeleaf-extras-java8time 을 선언해서 사용해야 하며

Spring Security를 사용하는 경우 thymeleaf-extras-springsecurity4 를 선언해야한다.
(둘다 기본 설정이 Thymeleaf 2 이하로 선언되어 있다.)

다음과 같이 추가한다.

<properties>
    <thymeleaf.version>3.0.0.RELEASE</thymeleaf.version>
    <thymeleaf-layout-dialect.version>2.0.0</thymeleaf-layout-dialect.version>
    <thymeleaf-extras-springsecurity4.version>3.0.1.RELEASE</thymeleaf-extras-springsecurity4.version>
    <thymeleaf-extras-java8time.version>3.0.0.RELEASE</thymeleaf-extras-java8time.version>
</dependency>

thymeleaf 3에서는 기존과 다르게 HTML, HTML5에 대해 모드 구분이 필요없어졌다. 하지만 spring은 아직 기본으로 HTML5를 설정하고 있어 이에 대한 warning을 제거하려면 다음과 같이 application.properties에 선언해준다. (꼭 해야할 필요는 없다.)

spring.thymeleaf.mode=HTML

Spring Boot 1.4.2-RELEASE

Spring Boot 1.4.2-RELEASE 가 나왔다.

일전에 언급했던 jpa auditing을 찾지 못하는 오류는 다시 수정되었다.

Spring Boot 1.4.1-RELEASE에서 spring-data-jpa의 auditing 이 동작하지 않는 문제 발생

MyBatis Java 8 관련 TypeHandler 설정 불필요

일전에 'Spring Boot war에서 MyBatis 사용시 TypeHandler scan 오류가 발생하는 현상' 이라는 글을 이곳에 썼었다.

시간이 지나 해당 글의 문제에 대한 패치가 되었다.

mybatis 3.4.0 이후 사용자는 더이상 java 8의 typehandler를 따로 선언할 필요가 없이 아래 dependeny만 추가하면 알아서 typehandler가 등록된다.
mybatis-typehandlers-jsr310

<dependency>
    <groupId>org.mybatis</groupId>
    <artifactId>mybatis-typehandlers-jsr310</artifactId>
    <version>1.0.1</version>
</dependency>

또한 boot war에서 mapper xml을 찾지못해 추가로 선언하던 SpringBootVFS 설정도 더 이상 하지 않아도 된다. (이 부분에 대한 릴리즈/패치 노트는 찾지 못했다.)

spring DispatcherServlet이 강제하는 이름들

boot를 사용하다보면 빈 생성을 참 편하게 할 수 있어 좋다.

ContitionalOnMissingBean 만 확인하고 개별 구현하고 연계처리를 별달리 하지 않아도 알아서 가져가서 써주니 편하다.

하지만 이따금 안되는 케이스들이 있는데 이번에 겪은 경우가 그랬다.

CookieLocaleResolver를 별도로 구현할 일이 있어 생성한 후 빈선언을 해주었는데 디버그를 해보니 acceptHeaderLocaleResolver (기본 LocaleResolver)을 사용하는 것이다.

boot의 설정상으론 해당 빈이 있는 경우 기본 LocaleResolver를 생성하지 않도록 되어 있는데 어째서 그런 것인가 살펴보니 boot가 아닌 spring mvc의 dispatcherServlet이 강제로 bean name을 고정해서 사용하고 있었다.

기본적으로 1개만 등록하는 빈들에 대해서 강제한 사항인 듯 싶다.

다음과 같은 이름들이 고정된 이름들이다.

• multipartResolver
• localeResolver
• themeResolver
• handlerMapping
• handlerAdapter
• handlerExceptionResolver
• viewNameTranslator
• viewResolver
• flashMapManager

이런 빈들에 대해서는 다음과 같이 이름을 지정하고 사용해야 한다.

@Component("localeResolver")
public class MyLocaleResolver extends CookieLocaleResolver {
    // 구현
}

int array 를 list 로 변환하기

array 를 list로 변환할 때 보통 다음과 같이 사용한다.

String[] strings = new String[] {"a", "b", "c"};
List<string> stringList = Arrays.asList(strings);

이 변환은 non primitive 타입에 대해서만 가능한 변환이다.

만약 primitive 타입인 int array를 Arrays.asList를 사용하면 반환값은 다음과 같다.

int[] ints = {1, 4, 3};
List<int[]> intList = Arrays.asList(ints);

즉 Arrays.asList를 통해 primitive 타입을 list로 변환을 할 수 없다.

다음과 같이 변환해야 한다.

int[] ints = {1, 4, 3};
List<Integer> intList = Arrays.stream(ints).boxed().collect(Collectors.toList());