- EnhancerTest 클래스에서 프록시 객체를 생성할 수 있는 Enhancer 객체를 생성하고 setSuperclass 메서드를 사용하여 타겟 클래스를 지정한다.
- setCallback 메서드에는 NoOp.INSTANCE(NoOption)을 입력했는데, 말 그대로 옵션이 없는 프록시객체로 설정하기 위함이다.
- NoOp로 설정하면 단순히 프록시 객체를 통해 타겟 클래스만 호출하는 것이고, MethodInterceptor로 설정하면 타겟 클래스 호출 전 후로 로직을 넣거나 매개변수를 변경하는 등의 작업이 가능하다. 후자의 경우도 다뤄보도록 할 예정이다.
- enhancer.create() 메서드를 호출하면 마침내 프록시 객체를 생성하게 된다.
- Object 형으로 반환되게 되지만 내부적으로는 앞서 설정한 타켓 클래스이기 때문에 instanceof를 사용하여 형 변환 또한 가능함을 확인할 수 있다. 결과적으로 enhance 에서 생성한 프록시 객체를 통해 MyService객체를 호출한다.
3.3) 결과
프록시 객체를 통한 MyService 호출 결과
사실 위 예제를 직접 작성했을땐 '그냥 객체 생성하고 호출하면 될것이지 왜 프록시까지 굳이 생성해서 호출하는걸까?' 라는 생각과 함께 비지니스 로직에 의해 동적으로 호출되어야 할 객체가 있다면 이를 사용했을 때 어느정도 효과를 볼 수 있지 않을까라는 생각도 들었다. 타겟 객체를 생성하는 게 아닌 호출하는 것이므로 메모리적으로도 좋지않을까? 혹시 누군가 알고계시다면 댓글로 달아주시길 부탁드리와요..
4. MethodInterceptor란?
프록시 객체의 콜백 기능 중 하나로, 프록시 객체에서 타겟 객체를 호출하기 전, 후로 비지니스 로직을 추가하거나, 타겟 클래스가 아닌 다른 객체의 메소드를 호출하거나, 인자 값을 변경할 수 있다.
구현 방법은 커스텀한 클래스에 MethodInterceptor 인터페이스를 상속받은 후 intercept 메서드를 오버라이드 한다.
- MethodInterceptor를 사용하여 아주 간단한 프록시 객체를 구현했다. 기존과 다른 건 MethodInterceptorTest 클래스를 구현한 후 callback 으로 설정했다는 점이다.
- 이 설정으로 인해 프록시 객체로 메서드를 호출하면 MethodInterceptorTest 클래스의 intercept 메서드가 호출되게 되어 before target Proxy 문자열 호출 후 타겟 클래스가 실행됨을 확인할 수 있다.
참고로 methodProxy.invokeSuper의 리턴 값은 타겟 객체의 리턴 값이다.
4.3) 결과
MethodInterceptor를 적용한 프록시 객체 호출 결과
5. 마치며
지금은 단순히 enhancer와 MethodInterceptor를 이용해 프록시를 구현하는 것만 해보아서 그런지 느낌만 알 뿐, 아직도 머릿속에서 정리가 되지 않은 느낌이다. 또한 어떻게 활용되는지도 크게 와닿지 않는다. 다음 게시글로 이 방식을 활용하여 다양한 예제를 만들어보도록 하겠다.
스프링 서버에서 DB 조회 결과를 내가 커스텀한 객체(DAO)로 가져오고 싶은 경우가 있다. 그럴 때 아래 예제처럼 resultType을 풀패키지 경로로 입력해야한다. 만약 입력한 BoardDAO 객체가 다른 쿼리에서도 사용된다면, 해당 쿼리의 resultType 또한 풀 패키지경로로 입력해야할 것이다. 추가로 패키지 경로가 바뀌거나 클래스 명이 바꿔버린다면? 모든 쿼리 설정파일을 바꿔줘야할 것이다.
이러한 문제를 미연에 방지할 수 있는 방법이 바로 Mybatis의 typeAlias(별명) 설정이다.
2. typeAlias
typeAlias는 패키지에 대한 별명을 지정할 수 있다. Mybatis 설정 파일에서 설정 가능하며, 아래 예제와 같이 typeAlias 태그의 type 값에 풀 패키지명을 입력하고, alias에는 별명을 지정한다.
typeAlias 설정
3. Mybatis 설정 파일 로드
Mybatis 설정파일을 로드하는 방법은 스프링의 context 설정 중 sqlSessionFactory를 설정하는 부분에 configLocation 값으로 mybatis 설정파일 경로를 넣어주면 된다. 내 설정파일은 클래스파일 경로에 포함되어있기 때문에 다음과 같이 classpath 로 경로설정을 하였다.
4. 적용
설정이 적용되면 resultType에 Alias로 값을 넣고 테스트해보자. 정상적으로 조회됨을 확인할 수 있을것이다.
mybatis 설정 에러가 발생하는 경우가 있는데, 그럴때는 seetings라는 태그가 configuration태그 내 첫번째로 위치하는지 확인하자.
스터디로 File 업로드, 다운로드 로직을 작성하던 도중, 특정 부분에 빨간줄이 등장했다. 자연스럽게 마우스 가져가보니 Exception!. 별생각 없이 add thrwos declaration 클릭. 상황종료.
이처럼 예외 처리에 큰 의미나 생각을 부여하지 않았다.
두둥등장한 에러.
그러던 어느날, 고객사측에서 에러 문의가 들어와 로그를 확인해보니 딱 봐도 DB 예외로 보이는 ERDBException이 발생하고 있었다.(커스텀 익셉션인 것!) 그래서 DB 예외라는 필터를 머릿속에 장착한 뒤 로직을 확인해보니... 이게웬걸.. 모든 예외에 대한 처리를 ERDBException으로 던지고있었다.
그리고 깨달았다. 예외처리를 제대로 하지 않으면 유지보수 시 혼란을 초래할 수 있다는 것을...
2. 예외? 에러?
예외에 대한 기본 개념을 정립하기 위해 구글링을 하니 "예외와 에러의 차이" 가 눈에 들어왔다. 사실 이 두 개념은 비슷하다고 생각했으나, 막상 확인해보니 예외 공부에 아주 중요한 키포인트가 됐던 내용이었다.
정리하면 에러는 시스템 레벨에서 발생하는 아주 심각한 수준의 문제이다. 예를들면 서버의 과부하가 걸려 발생하는 OutOfMemory 같은 것이다. 이러한 에러는 프로그래머가 미리 예측하지 못하며 로직으로 처리할 수 없다.
이에반해 예외는 프로그래머가 작성한 로직으로 인해 발생하는 문제이다. 미리 예측하여 처리할 수 있기 때문에 올바른 처리방법을 통해 핸들링하는 것이 중요하다.
위 코드에 빨간줄이 아주 많다; 빨간줄이 나타나는 이유는 예외처리를 하지 않아서인데, 이처럼 예외처리를 꼭 해줘야하는 것들이 있다. 이러한 예외들을 CheckedException이라고 한다. 말 그대로 컴파일 시점에서 체크해주는 예외이다.
런타임 시점에 발생하는 예외들도 있는데 이는 UnCheckedException이라고도 하고 RuntimException이라고 한다. 이러한 예외는 컴파일 시점에 체크되지 않아 위 소스처럼 에러가 뜨지 않는다.
4. try, catch, finally
예외를 처리하기 위해서 사용하는 기본적인 문법이 있다. 바로 try, catch, finally이다.
try는 예외 발생 가능성이 있는 로직이 포함된 블럭, catch는 예외가 발생했을 때 처리되는 로직이 포함된 블럭, finally는 예외가 발생하던 안하던 최종적으로 처리되는 로직이 포함된 블럭이다.
간단한 예제를 통해 실습해보자.
예외 멈춰!
예외 멈춰! 결과
현재 File 객체의 매개변수 값으로 텍스트파일의 경로를 넣어놨는데, 이 경로는 실제로 존재하지 않는 파일의 경로이다. 이로인해 try 문 안의 fis = new FileInputStream 부분에서 FileNotFoundException (FileNotFoundException 예외는 Exception을 상속하고 있음) 이 발생하게 되는데, 이때 catch 블록으로 이동하여 예외 처리 후, 최종적으로 finally문에서 스트림을 닫게 된다.
그럼 이런 의문이 들 수 있다.
Q : catch의 매개변수에 Exception을 넣으면 결론적으로 try 문에서 발생한 모든 예외들은 저 하나의 catch문에서 처리되는게 아닌가? 그럼 다양한 예외에 대한 핸들링하지 못하잖아?
맞다. 저렇게 무작정 Exception으로만 넣게되면, 모든 예외를 한곳에서 핸드링하는 격이기 때문에 상황에 맞게 예외를 분기해서 처리해야 한다. 한곳에서 처리하는 것이 효율적인 예외도 있겠지만, 예를 들어 로직에 SQLException과 FileNotFoundException 예외가 발생할 수 있는 상황이라면 각각의 예외에 대한 세부 로그를 남기는 등의 예외처리를 하면 좋지 않을까 싶다. (참고로 모든 예외를 Exception으로 통일한 프로젝트도 있었다.)
5. throw, throws
예외란 프로그래머가 작성한 로직에 의해 발생된다. 그렇다면 프로그래머가 예외를 발생시킬수도 있을까? 있다. 추가적으로 예외에 대한 책임을 전가할수도 있다. 이게 바로 throw와 throws이다.
- throw는 예외를 강제로 발생시킨 후, 상위 블럭이나 catch문으로 예외를 던진다.
throw
위 예제는 main 메서드에서 myException메서드를 호출하고, 여기서 throw를 통해 Exception을 강제로 발생시키고 있다.
때문에 catch 블럭으로 처리가 위임되고, 여기서 예외를 처리하고 있다. 이는 콘솔 로그를 통해 알수있다.
- throws는 예외가 발생하면 상위메서드로 예외를 던진다.
throws
일반적으로 throws를 사용하면 try, catch 구문이 생성되지 않는 것을 확인할 수 있는데, 이 이유는 throws구문에 의해 예외에 대한 처리를 호출부로 위임하기 때문이다.
throw를 통해 예외를 발생시키고 throws는 이 예외를 밖으로 던져버리고 있다.
추가적으로 이 두가지를 합친 방식도 있다.
throw + throws는 예외처리를 catch문에서도 하고, 호출부로 예외를 던진다.
throw + throws
22줄에 throw e를 통해 예외를 발생시키면 throws에 의해 상위 메서드로 예외를 던지게 된다.
- Controller로 들어온 파라미터를 가공하거나 수정 기능을 제공하는 객체이다. 교재에서는 이를 사용해 Controller로 들어온 특정 파라미터에 세션 정보를 가공하여 넣어주었다.
- Argument Resolver를 Controller 단에서 사용하면 중복 코드(HttpSession에서 세션 로드, HttpServletRequest에서 요청 url 및 ip 정보 로드 등)를 깔끔하게 처리할 수 있다. > 예제를 보면 이 말의 의미를 알 수 있다.
- 예제에서는 LoginUser 어노테이션이 붙은 SessionUser 객체에 대해 Argument Resolver를 설정해주었다.
3. 예제
3.1. @LoginUser.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
package com.ssk.springboot.config.auth;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;
import java.lang.annotation.RetentionPolicy;
/*
* Target : 어노테이션이 생성될 수 있는 위치 지정. PARAMETER면 메소드의 파라미터로 선언된 객체에서만 사용 가능
* Retention : 어노테이션의 메모리 생명 주기 지정. 런타임에도 해당 어노테이션 객체는 메모리에 올라가있음
