close
프로필 배경
프로필 로고

Dev Factory

Spring Framework · 2023. 1. 10. fullscreen 넓게보기

[Spring] @ModelAttribute 처리 흐름

목차

ArgumentResolver

Spring Framework에서 ArgumentResolver는 굉장히 중요한 핵심 개념이다

사용자의 Request가 들어오는 순간 처리 메커니즘을 간단하게 알아보자

1. 사용자의 Request가 DispatcherServlet으로 들어온다
2. DispatcherServlet은 들어온 Request를 처리할 수 있는 Handler를 조회
3. 조회한 Handler를 컨트롤할 수 있는 HandlerAdapter 조회
4. HandlerAdapter가 본인이 컨트롤하는 Handler를 invoke

 

4단계 :: Handler를 invoke하는 프로세스에서 ArgumentResolver가 활용된다

  • 이 말이 무슨 의미인지 정확하게 이해가 되지 않을 수 있으니 상세하게 풀어서 살펴보자

 

1.png

현재 RestController인 TestController에 Endpoint GET /hello가 존재한다

 

위의 과정에 대입해보면 다음과 같다

1. 사용자의 GET /hello가 DispatcherServlet으로 들어온다
2. DispatcherServlet은 들어온 Request를 처리할 수 있는 Handler를 조회
→ @GetMapping("/hello") invokeHello
3. 조회한 Handler를 컨트롤할 수 있는 HandlerAdapter 조회
→ RequestMappingHandlerAdapter
4. HandlerAdapter가 본인이 컨트롤하는 Handler를 invoke

 

여기서 RequestMappingHandlerAdapter는 invokeHello를 invoke 하기 전에 Handler(invokeHello)가 Hello라는 Object Data를 활용할 수 있도록 @ModelAttribute Hello hello라는 파라미터를 정제하는 과정을 수행한다

 

HandlerMethodArgumentResolver

2.png

이 중에서 과연 위의 invokeHandler의 @ModelAttribute Hello hello를 정제할 수 있는 ArgumentResolver가 무엇인지 확인해보자

 

HandlerMethodArgumentResolverComposite - "getArgumentResolver"

3.png

무슨 ArgumentResolver가 선택될지 디버깅을 해보니 ServletModelAttributeMethodProcessor가 선택이 되었다

 

4.png
5.png

클래스 구조를 파악해보니 결국 @ModelAttribute에 대한 정제를 담당하는 ArgumentResolver는 ModelAttributeMethodProcessor임을 확인할 수 있다
  • 이 추정에 대한 확신을 가지기 위해서 디버깅을 통해서 실제로 ModelAttributeMethodProcessor로 흐름이 넘어가는지 확인해보자

 

6.png
7.png

ModelAttributeMethodProcessor로 넘어옴을 디버깅을 통해서 확인할 수 있다

 

 

ModelAttributeMethodProcessor

ModelAttributeMethodProcessor가 @ModelAttribute에 대한 처리 메커니즘을 가진다는 것을 위의 디버깅 과정을 통해서 확인하였다

그러면 이제 ModelAttributeMethodProcessor의 내부 동작 메커니즘을 확인해보자

 

supportsParameter

8.png

일단 @ModelAttribute라는 바인딩 애노테이션이 어떤 파라미터 타입에 적용되는지 살펴보자

  • 코드를 보면 !BeanUtils.isSimpleProperty라는 부분을 확인할 수 있다

9.png

따라서 @ModelAttribute는 위의 코드에서 볼 수 있는 타입이 아니면 적용될 수 있는 것이다

 

resolveArgument

어떤 파라미터에 적용 가능한지 확인을 하였으니 이제 resolveArgument의 동작 흐름을 알아보자

10.png

resolveArgument에 진입하게 되면 파라미터 이름, ModelAttribute 속성, ...등 여러가지 정보를 얻는다

 

그리고 가장 핵심적인 createAttribute부분으로 진입하게 된다

  • resolveArgument의 최종 응답 값은 attribute이다
  • 따라서 우리는 createAttribute를 통해서 Hello hello라는 Object에 RequestData가 Binding됨을 추측할 수 있다

 

 

resolveArgument의 세부적인 흐름 파악해보기

1. ServletModelAttributeMethodProcess - "createAttribute"

11.png
12.png
13.png

createAttribute의 getRequestValueForAttribute의 값이 null로 도출됨에 따라 super.createAttribute로 흐름이 넘어가게 된다

 

4.png

  • 이 구조를 통해서 super.createAttribute는 결국 ModelAttributeMethodProcessor로 넘어감을 확인할 수 있다

 

2. ModelAttributeMethodProcess - "createAttribute"

14.png

GET /hello : invokeHello의 파라미터인 Hello hello에 대한 생성자를 얻는듯한 로직을 볼 수 있다

 

@Getter
@AllArgsConstructor
static class Hello {
    private Long id;
    private String name;
}

현재 Hello는 위와 같이 구성되어 있고 위의 로직을 통해서 어떠한 생성자를 얻는지 확인해보자

  • 사실 당연히 @AllArgsConstructor가 존재하므로 public Hello(Long id, String name)을 얻을거라고 예상된다
    • 추가적으로 자바 기본 상식이지만 @AllArgsConstructor에 의해 생성자가 이미 존재하기 때문에 컴파일러가 기본 생성자는 만들어주지 않는다

 

3. BeanUtils - "getResolvableConstructor"

15.png

예상한대로 public Hello(Long id, String name) 생성자를 가져옴을 확인할 수 있다

 

4. ModelAttributeMethodProcess - "constructAttribute"

16.png

파라미터 Hello의 선언된 생성자를 얻어내고 constructAttribute흐름으로 넘어가보자

  • constructAttribute에서 요청으로 들어온 데이터들의 Binding이 이루어지는 느낌이다

 

17.png

현재 얻은 Hello의 생성자는 Long id, String name 총 2개의 파라미터를 보유하고 있기 때문에 위의 if 로직에는 포함되지 않는다

 

계속해서 다음 코드들을 살펴보자

18.png

  • 위의 코드들은 Binding을 위한 기본적인 프로세스를 진행한다고 생각하면 된다

 

19.png

  • 현재 요청은 http://localhost:8080/hello?id=1&name=spring형식으로 진행되고 있다

 

20.png

일련의 과정을 통해서 Object[] args에 현재 요청으로 들어온 데이터들을 담았고 이제 BeanUtils.instantiateClass로 흐름을 넘겨보자

 

5. BeanUtils - "instantiateClass"

21.png

첫번째로 일단 public Hello(Long id, String name)에 접근 가능하도록 ReflectionUtils를 통해서 설정해주었다

 

22.png

결정적인 코드가 도출되었다

 

@Getter
@AllArgsConstructor
static class Hello {
    private Long id;
    private String name;
}

현재 Hello Class의 구성은 위와 같고 @AllArgsConstructor을 가지고 있다

 

이에 따라서 BeanUtils의 instantiateClass에서는 생성자 : public Hello(Long id, String name) / 요청 데이터 : [id: 1, name: "spring"]을 이용하여 Constructor의 newInstance을 호출한다

Constructor의 newInstance를 통해서 완성된 Hello(id: 1, name: "spring") 인스턴스가 만들어진다

 

간단한 Reflection Test

@Test
void test() throws NoSuchMethodException, InvocationTargetException, InstantiationException, IllegalAccessException {
    Object[] argsWithDefaultValues = {12345L, "Hello Spring World"};
    
    Constructor<TestController.Hello> constructor = TestController.Hello.class.getConstructor(Long.class, String.class);
    constructor.setAccessible(true);
    TestController.Hello helloWorld = constructor.newInstance(argsWithDefaultValues);

    System.out.println(helloWorld.getId());
    System.out.println(helloWorld.getName());
    assertThat(helloWorld.getId()).isEqualTo(12345L);
    assertThat(helloWorld.getName()).isEqualTo("Hello Spring World");
}

23.png

 

6. 결론

24.png

ModelAttributeMethodProcessor의 createAttribute는 Hello(id: 1, name: "spring")를 정제된 결과로써 받고 ArgumentResolver의 resolveArgument의 결과는 Hello(id: 1, name: "spring")로 마무리된다

 

 

의문점

하지만 여기서 다음과 같은 의문이 들 수 있다

어떤 블로그에서는 @ModelAttribute로 바인딩할때 setter가 없으면 안된다던데?
  • 이미 위에서 이런 의견에 대한 반례를 보였다

 

요청으로 들어온 데이터에 대한 DTO Binding을 다음 예시 상황을 통해서 알아보자

1. Default Constructor + getter + setter

@Getter
@Setter
static class Hello {
    private Long id;
    private String name;
}

일단 DTO에 기본 생성자 + setter가 존재할 경우 진행되는 프로세스는 다음과 같다

  • 여기서 @NoArgsConstructor가 없는데 기본 생성자가 어디있냐?라고 생각하는 사람 또한 존재할 수 있다
    • 위에서도 말했듯이 컴파일러는 클래스 내부적으로 생성자가 없을 경우 파라미터가 없는 기본 생성자 : public Hello(){}를 만들어준다

 

25.png

표시된 해당 블럭에서 ClassType에 대한 인스턴스를 생성한다

  • 물론 Object 내부 필드들은 ReferenceType = null / PrimitiveType = default value를 가지게 된다

 

그 이후 DataBinder에 의해서 값들이 binding되는것이다

26.png
27.png
28.png

1. 기본 생성자에 의해서 Hello (id: null, name: null) 객체 생성
2. DataBinder의 setValue를 통해서 setId, setName -> 완전한 Hello (id: 1L, name: "spring") 객체 생성

 

2. AllArgsConstructor + getter + setter

29.png

상세한 프로세스는 위에서 이미 디버깅을 통해서 확인하였기 때문에 넘어가고 중요한 부분만 살펴보자

모든 필드를 갖는 생성자가 존재하기 때문에 위의 로직 상에서 BeanUtils.instantiateClass를 통해서 Hello(id: 1, name: "spring) 객체가 탄생한다

 

30.png

그 이후 ModelAttributeMethodProcessor의 resolveArgument로 흐름이 넘어와서 진행되다가 bindRequestParameters를 호출함을 확인할 수 있다

 

31.png
32.png
33.png

마찬가지로 DataBinder로 들어와서 setter로 Binding됨을 확인할 수 있다

1. @AllArgsConstructor, Constructor.newInstance(args...)를 통해서 Hello (id: 1L, name: "spring") 객체 생성
2. DataBinder의 setValue를 통해서 setId, setName -> Hello (id: 1L, name: "spring")
→ 단순하게 객체 내부 필드 값을 덮어씌우는 것이다

 

3. AllArgsConstructor + getter

모든 필드가 있는 생성자만 존재하고 setter가 없는 상황은 위에서 디버깅을 통해서 파악을 하였다

@AllArgsConstructor, Constructor.newInstance(args...)를 통해서 Hello (id: 1L, name: "spring") 객체 생성

 

그런데 여기서 추가적으로 확인할 부분은 다음과 같다

  1. setter가 없는데 DataBinder로 흐름이 넘어가는지
  2. 만약 DataBinder로 흐름이 넘어간다면 어떤 형식으로 Binding되는지

34.png

결론적으로 말하면 DataBinder의 setValue로 흐름이 넘어가지 않는다

  • 그 이유는 위의 코드에서 보이는 PropertyHandler의 특정 속성 때문이다

 

setter 존재 O

@Getter
@Setter
@AllArgsConstructor
static class Hello {
    private Long id;
    private String name;
}

35.png

setter가 열려있기 때문에 PropertyHandler의 writable값이 true이고 그에 따라서 DataBinder의 setValue 부분으로 흐름이 넘어간다

 

setter 존재 X

@Getter
@AllArgsConstructor
static class Hello {
    private Long id;
    private String name;
}

36.png

setter가 닫혀있기 때문에 PropertyHandler의 writable값이 false이고 그에 따라서 DataBinder의 setValue 부분으로 흐름이 넘어가지 않는다

 

4. Default Constructor + getter

그러면 기본 생성자만 존재하고 setter가 없을 경우 어떤 상황이 벌어질지 한번 결과로 살펴보자

@Getter
static class Hello {
    private Long id;
    private String name;
}

37.png

Hello의 모든 필드가 null로 바인딩 됨을 확인할 수 있다

 

이 이유는 다음 흐름을 통해서 알아보자

38.png

  • 일단 createAttribute에서 Hello는 현재 기본 생성자만 보유하고 있기 때문에 Hello(id: null, name: null)을 반환하게 된다

 

39.png

  • 그 이후 resolveArgument 프로세스로 돌아와서 bindRequestParameters 흐름으로 넘어간다

 

40.png

바로 이 시점에서 위의 실험 결과에 따라 setter가 존재하지 않기 때문에 PropertyHandler의 writable값은 false로 설정되고 그에 따라서 DataBinder의 setValue로 흐름이 넘어가지 않는 것이다

 

41.png

  • 그 결과로 결국 resolveArgument의 최종 결과값은 값이 바인딩 되지 않은 Hello(id: null, name: null)가 되는 것이다

 

5. Default Constructor + AllArgsConstructor

과연 기본 생성자 + 모든 필드를 가지는 생성자가 동시에 존재할 경우 어떤 프로세스로 진행될지 한번 살펴보자

@Getter
@NoArgsConstructor
@AllArgsConstructor
static class Hello {
    private Long id;
    private String name;
}

42.png
43.png

보이는 결과로 알 수 있듯이 생성자가 여러개 존재하면 기본 생성자가 선택된다

 

 

@ModelAttribute 처리 흐름 결론

위의 여러 디버깅 및 실험을 통해서 @ModelAttribute 처리 흐름은 다음과 같이 구조화시킬 수 있다

1. @Getter 필수
2. @Getter + @Setter / @Getter + @AllArgsConstructor 조합이면 정상적으로 바인딩
3. 기본 생성자만 존재 or @NoArgsConstructor + @AllArgsConstructor 조합이면 setter는 강제적이다

 

1. 정상 바인딩 조합

@Getter + @Setter
@Getter + @AllArgsConstructor
@Getter + @Setter + @NoArgsConstructor
@Getter + @Setter + @AllArgsConstructor
@Getter + @Setter + @NoArgsConstructor + @AllArgsConstructor

 

2. null 바인딩 조합

@Getter
@Getter + @NoArgsConstructor
@Getter + @NoArgsConstructor + @AllArgsConstructor

 

3. Resolved ~~ Could not find acceptable representation 예외 발생 조합

@Getter가 없는 모든 상황

 

 

 

Skill/Spring Framework 관련 글
더 보기

티스토리툴바