제목에 맞는 예인지 모르겠으나 며칠간 spring3 환경에서
session정보를 로깅하기 위해 AOP 적용한다고 삽질하였습니다.
aop session 등의 키워드를 가지고 계속 검색하면서
joinpoint의 getAgrs() 등의 메소드를 이용하여 반복문을 돌리면서 request 객체를 얻는 등
이상한 코딩을 하고 있었죠.
그러다 문득, 내가 지금 뭘하고 있는거지? 이게 맞는건가??? 하는 생각이 들더군요.
그러면서도 다른 이슈에 치이면서 잡생각하지말고 구현에 집중하자라면서
다시 이상한 코딩을 하기 시작했습니다.
그러다 구현까지 된 시점에서 이상한 bean생성방법과 이상하게 작성된 구현을 보고
KSUG에 문의하기에 이르렀습니다.
그때 AOP를 왜 적용하는지에 대한 질문과 함께, interceptor에 대한 안내를 해주시더군요.
전 이미 login 체크 등을 필터로 빼놓은 상태였는데,
왜 컨트롤단으로 들어오는 세션정보를 로깅하려는 것을 AOP로 작성하려 하였을까요??
왜 interceptor나 filter를 생각하지 않았을까요??
기술에 먼저 집착한 제 실수가 아니었나 생각해봅니다.
목적은 세션정보 로깅입니다. request에 대한 접근이 필요했죠. 그럼 controller layer의 전처리나 후처리가 제일 알맞겠죠.
그럼 간단합니다. servlet의 filter나 다른 프레임워크의 interceptor를 써야합니다.
그런데 모든 controller 단에서 모든 이라는 워드를 떠올리고 바로 생각해낸게 AOP인겁니다.
접근해보지 않았던 기술에 대해 해봐야지라는 생각을 우선했던 겁니다.
큰 반성을 하고 시야를 좀 트일 수 있는 기회가 되길 바래야겠습니다.
'Programming' 카테고리의 다른 글
aws ec2 instances log centralized (0) | 2016.08.17 |
---|---|
programming : 프로그래밍을 할 때에는 도메인 이해는 선택이 아닌 필수. (0) | 2013.06.13 |
[오늘의 명언] (0) | 2012.12.18 |
[programming] 가독성..? (0) | 2012.03.09 |