[회고] 221230 : @RequestBody 의 데이터를 AOP에서 불러오기
프로젝트의 요구조건 중, Request Body로 전달되는 username 과 password의 길이,포맷에 대한 필터링을 AOP로 분리해야한다는 조건이 있었다. AOP는 일반적인 메서드와 다르게, 메인 플로우의 흐름 밖에 위치하기 때문에, 매개변수에 곧바로 접근하여 가져오는 것이 일반적인 사용법과 다르다.
AOP를 적용할 클래스, 패키지를 직접 지정한 뒤, JointPoint 라는 객체를 통해 실행 할 메서드들과 그곳에 전달되는 매개변수에 접근한다. 단, 이 때 매개변수는 hashCode 로 제공되기에, .get~~와 같이 내부에 정의된 메서드를 실행시켜 내부의 값에 접근하여 가져오기가 매우 어렵다.
따라서, 나는 Reflection API를 적용하여, 해당 클래스를 가져와 클래스의 메소드를 invoke함으로서 username을 가져올 수 있게 하였다. 하지만, 이 때 Reflection API를 잘못사용해서 그런지 의도대로 동작하지 않았고, 곧바로 다른 방법을 찾아보게 되었다. 내가 집중한 것은 arg로 가져오는 것의 타입이 Object라는 것, 그리고 이것이 RequestDto 라는 hashCode로 정확히 그 역할을 가져온다는 것 이었다. 물론 모든 객체의 부모가 Object이긴 하지만, 확실하게 이 object가 RequesDto라는 것을 인지하고 있네? 그렇다면 RequesDto로 형변환을 시켜주면 어떻게 될까..? 하는 추측을 했다.
결과는..
잘동작한다!
Object[] args = joinPoint.getArgs();
for(Object arg : args) {
System.out.println(arg); // SignUpRequestDto's hashcode
if(arg instanceof SignUpRequestDto){
SignUpRequestDto dto = (SignUpRequestDto) arg;
String username = dto.getUsername();
String password = dto.getPassword();
System.out.println(username + " " + password); // work!
break;
}
}이런 과정을 거치면서, AOP에 대한 많은 실험을 거칠 수 있었고, 이에따라 AOP가 어떤 흐름으로 진행되는지 이해하게 되었다. 항상 어떤 시행착오를 거치고 성공하면, 그전에 했던 모든실수의 원인이 기억이 나고 스스로 민망해지는 순간들이 있다. 하지만, 백문이불여일타 라고 확실히 나는 뭔가를 손으로 일단 써봐야 그다음 이해를 하는 경향이 강한 것 같다. 공식문서와도 얼른 친해져야하는데.. 걱정이다. 또, 프로젝트를 지속적으로 진행함에따라 자바에 대한 기본기, 스프링에 대한 기본기와 철학을 계속 잊어버리게 되는데, 책으로서 보충하던지 시간을내어 복습을 하던지 기본기를 잃지않도록 스스로 인지해야할 것 같다는 성찰을 했다.
[TodayKeywords] 오늘 공부한 키워드
[NextKeyworks] Study Queue
- HTTPS
- SOLID
- loop label
- CSV
- 파일입출력
- UML
- UTC
- epoch time / Instant time
- MVC
- URL ClassLoader
- Secure ClassLoader
- JNI
- GC
- HOF
- 자바 해시코드(hashCode)
- OSI 7 계층
- PCB
- 스프링 설계철학
- RESTful
- 준 영속성
- 지연로딩
- 프록시객체
- jpa - mybatis 의 차이
- orm - mapper 의 차이
- 쿠키/세션/로컬 스토리지
- HttpMessageConverter
- 서블릿
- ACID