한가로운 어느 일요일, 저는 평소와 같이 열심히 테스트 코드를 작성하고 있었습니다. 테스트 코드를 작성하던 중, 언젠가 테스트 코드에서는 의존성 주입이 안된다는 사실을 알고 있냐는 크루의 물음이 떠올랐습니다. 그동안 편의를 위해 Autowired를 마구 쓰던 저는 이번 기회에 한번 테스트해보자는 마인드로 생성자 주입을 하도록 코드를 변경해 보았습니다.
그 결과…
@SpringBootTest
public class ProductServiceTest {
private final ProductService productService;
public ProductServiceTest(ProductService productService) {
this.productService = productService;
}
...
으악
역시 안되는군요.. 크루는 거짓말을 하지 않았습니다. 그렇다면 왜 되지 않는 걸까요? @SpringBootTest를 써 주었으니 문제가 없는게 아닐까요? 대충 에러 메세지를 보아 하니.. ProductService라는 파라메터에 대한 ParameterResolver가 등록되지 않았다고 뜨는군요. 이 부분을 한번 구글의 힘을 빌려 찾아 보겠습니다.
해결법 자체는 생성자에 있는 파라메터를 제거하고 @BeforeEach에서 초기화를 해주거나 @Autowired로 필드를 초기화한다고 나오는 거 같습니다. 해결법은 알겠고.. 원인은 무엇일까요?
무엇이 문제였을까?
@SpringBootTest를 붙이게 되면 Junit Jupiter에 SpringExtension이 자동으로 등록되어 사용됩니다. 조금 소스를 까보면서 해결책이 있을지 찾아보겠습니다.
* <p><strong>WARNING</strong>: If a test class {@code Constructor} is annotated
* with {@code @Autowired} or automatically autowirable (see {@link TestConstructor}),
* Spring will assume the responsibility for resolving all parameters in the
* constructor. Consequently, no other registered {@link ParameterResolver}
* will be able to resolve parameters.
읽어보니 @Autowired가 달린 Constructor나 TestConstruct 어노테이션을 사용한 경우에 대해서만 생성자 내의 모든 파라메터를 처리한다고 하네요. 추측하건데 프로덕션 코드에서는 Autowired 어노테이션을 생략 가능하지만, SpringExtension에서는 Autowired 어노테이션이 생략 불가능해서 위와 같은 에러가 떴던 거 같습니다.
제 생각으로는 아마, 테스트 클래스를 관리하는 주체가 Spring이 아닌 Junit5이기 때문에 Junit의 방식을 따라야 하는데, Junit에서는 빈을 주입하기 위해서는 Junit에서 제공하는 ParameterResolver를 통해 주입해야 하기 때문인 것 같습니다. Junit의 파라메터 중 어떤 파라메터를 스프링의 ApplicationContext에서 주입받아야 하는지 구분하기 위해 Autowired 어노테이션에 의존하게 된 것 같습니다.
결론적으로, Autowired는 필수적으로 써주어야 합니다. 주석 내에 @TestConstruct라는 어노테이션이 있어 이를 사용해 보겠습니다. @TestConstruct는 생성자 주입을 어떻게 처리할 지 결정한다고 보는게 가장 좋을 것 같습니다. ALL 옵션인 경우, 모든 생성자에 Autowired가 달려있는 것으로 간주하며 생성자 주입을 시켜 줍니다. ANNOTATED 옵션인 경우 관련 어노테이션(@Autowired, @Value, …)이 붙어있는 경우에만 생성자 주입이 동작합니다.
@SpringBootTest
@TestConstructor(autowireMode = AutowireMode.ALL)
public class ProductServiceTest {
private final ProductService productService;
public ProductServiceTest(ProductService productService) {
this.productService = productService;
}
5. 이후 다시 OAuth & Permissions로 가면 봇의 OAuth Token이 발급됩니다.
슬랙 메세지 전송
슬랙 봇도 만들고 OAuth Token도 발급받았으니 본격적으로 슬랙 메세지를 전송해 봅시다.
슬랙 메세지 전송 API는 다음과 같습니다.
채널 ID는 채널 정보의 하단에 존재한다.
언뜻 살펴보기에.. Authorization 헤더에 위에서 받아온 토큰을 입력해 주고, channel에 채널ID 라는걸 넣어주면 잘 동작할 것 같습니다. 그렇다면 ChannelID는 뭘까요? 맨 아래에 채널 ID라는게 따로 존재하는 모습을 볼 수 있습니다. 이제 전달해주기 위한 모든 데이터들을 다 얻었으니 본격적으로 슬랙에 메시지를 던져보기 위한 코드를 작성해 보겠습니다. 외부 API를 호출하므로 RestTemplate를 통해 Api를 사용하겠습니다.
public void index() throws JsonProcessingException {
final var token = "슬랙봇_토큰";
final var url = "https://slack.com/api/chat.postMessage";
final var channelID = "채널아이디";
HttpHeaders httpHeaders = new HttpHeaders();
httpHeaders.add(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE);
httpHeaders.add(HttpHeaders.AUTHORIZATION, "Bearer " + token);
SlackMessage slackMessage = new SlackMessage(channelID, "hello world!");
ObjectMapper objectMapper = new ObjectMapper();
String jsonData = objectMapper.writeValueAsString(slackMessage);
HttpEntity<String> request = new HttpEntity<>(jsonData, httpHeaders);
String response = restTemplate.postForObject(url, request, String.class);
System.out.println(response);
}
사실 위 방식을 그대로 잘 따라했다면 에러가 뜹니다..ㅎ 코드를 짜고 요청을 계속해서 날려보아도 봇이 채널에 존재하지 않는다는 에러가 발생하였습니다. 구글링 결과 봇 권한을 더 주어야 한다고 슬랙 봇 권한을 보니 채널에 참여하는것도 권한을 줘야 한다고 합니다. 따로 권한을 부여하여 주고 채널을 새롭게 파서 채널에 봇을 입장시켜 줍시다~
Java의 log4j의 후속버전입니다. log4j의 아키텍처 기반으로 재작성 되었으며, slf4j을 지원하기 때문에 다른 logger로 얼마든지 바꿀수 있게 구현되어 있습니다.
로그 레벨
사전 지식으로 로그 레벨에 대해서 알아야 합니다.
ERROR : 요청을 처리하는 중 오류가 발생한 경우 표시하는 로그입니다.
WARN : 처리 가능한 문제, 향후 시스템 에러의 원인이 될 수 있는 경고성 메시지를 나타냅니다.
INFO : 상태변경과 같은 정보성 로그를 나타냅니다.
DEBUG : 프로그램을 디버깅하기 위한 정보를 표시합니다.
TRACE : 추적 레벨을 Debug보다 훨씬 상세한 정보를 나타냅니다.
로그 레벨의 경우는 역순으로, ERROR이 가장 높고, TRACE가 가장 낮은 레벨입니다.
Logging With Springboot
spring-boot-starter-web 의존성 추가
application.yml 또는 logback-spring.xml에서 설정하는것이 포인트입니다.
설정할 부분은 대략 다음과 같습니다.
콘솔, 파일, DB 등 로그를 출력하는 방법을 지정하는 Appender
출력할 곳을 정하는 logger
logback 설정 파일 경로는 /resources/logback-spring.xml입니다.
Configuration
Appender에서 콘솔에 출력되는 형식을 지정합니다.
Pattern에서 지정한 방식대로 시간/레벨 등이 설정된 후 콘솔에 메시지를 저장합니다.
filter, encoder, policy 등을 지정할 수 있습니다.프로젝트에서는 로그가 특정 크기(10MB)가 되면, 새로운 로그를 저장하도록 구현할 계획이므로 RollingFileAppender을 사용합니다.
RollingFileAppender엔 등록되어 있는 몇가지 정책(RollingPolicy)들이 있습니다. 이 중 파일 크기 기반으로 정책을 설정할 계획이므로 SizeBasedTriggeringPolicy를 사용하였습니다. 또한, 저장되는 로그 파일을 10개씩 관리하기 위해 FixedWindowRollingPolicy를 같이 사용하였습니다.
레벨에 따라서 적용되는 필터입니다. 이번 예시에서는 ERROR 레벨에서만 로그를 찍도록 하기 위해 ERROR 단계에서의 onMatch 속성을 ACCEPT로 설정하고, ERROR 레벨이 아니라면 로그를 찍지 않도록 하기 위해 ERROR 레벨이 아니라면 무시하도록 DENY를 걸어주었습니다. 참고로 값들에 대한 설명은 다음과 같습니다.
이번 예제에서는 rollingPolicy와 triggeringPolicy를 사용하였습니다. triggeringPolicy는 rollover가 발생하는 시점이며, rollingPolicy는 rollover 발생 시 처리 방식에 대해 명시하였습니다. TriggeringPolicy인 SizeBasedTriggeringPolicy로 인해10MB의 파일 크기가 넘어간다면 FixedWindowRollingPolicy가 발생하여 <file>에 적힌 파일명에 숫자를 붙여서 다른 파일로 보관하며, 10개의 파일을 보관합니다.
테스트
적용을 다 했으면, 이제 직접 테스트해 봅시다. 예외를 터트리면 ERROR 단계일거 같으니, 한번 아무렇게나 예외를 터트려 봅시다.
public Group findGroup(Long id) {
throw new IllegalArgumentException("hello world!");
//return groupSearchRepository.findById(id)
// .orElseThrow(() -> new GroupException(NOT_EXIST));
}
실행했는데 로그 파일은 생성되지만, 슬프게도 아무 로그도 찍히지 않는 문제가 발생했습니다. 문제가 무엇일까요? 답은 예외를 터트린다고 하더라도 로그 레벨이 ERROR이 아니라는 점입니다.
즉, 예외를 처리하는 ControllerAdvice에서 Logger.error 메서드를 호출하여서 명시적으로 ERROR 로그 레벨의 로그를 출력해 주면 됩니다. 이때 Exception 객체를 넘겨주면, StackTrace도 함께 출력됩니다.
테스트 해보다가 참고로 알게된 점은.. 서비스 테스트에서 예외를 터트리더라도 Advice로는 가지 않는 문제가 있었습니다. ControllerAdvice는 컨트롤러 단에서 터지는 예외에 대해서만 처리를 하기 때문에 서비스 테스트에서 백날 예외를 터트려 봐야 Advice로 들어가지 않는다고 하더라구요.. 이거때문에 삽질을 좀 오랜시간 했습니다..ㅠ
서비스를 Transaction 서비스, 비즈니스 서비스로 나눈다고 하면 이 중 Transaction 서비스를 부가기능이라고 생각하면 됩니다.
우리가 원한건 비즈니스 서비스고, 부가적인 처리가 필요하다는 관점
주로 인프라 관련 처리들이 부가기능
스프링은 어드바이스를 인터셉터로 모델링하고 조인 포인트 주변에 인터셉터 체인 유지
포인트 컷(Pointcut)
어드바이스를 적용할 조인 포인트를 선별하는 모듈
타겟(Target)
부가기능(Advice)을 적용할 대상
프록시(Proxy)
클라이언트와 타겟 사이에서 부가기능을 제공하는 객체
스프링에서 프록시는 JDK 동적 프록시 또는 CGLIB 프록시로 구현
스프링에서의 프록시를 제공하는 두가지 방법 : 리플렉션(JDK), CGLIB 라이브러리 사용
스프링은 JDK가 기본, 스프링 부트에서 CGLIB 라이브러리 사용
JDK 프록시 → 메서드 단위, 인터페이스여야만 사용 가능
동적 프록시(Dynamic Proxy)
공식 문서의 설명을 따다 가져오면 다음과 같습니다.
동적 프록시 클래스 는 클래스 인스턴스 의 인터페이스 중 하나를 통한 메서드 호출이 균일한 인터페이스를 통해 인코딩되고 다른 객체에 전달되도록 런타임에 지정된 인터페이스 목록을 구현하는 클래스입니다.
말이 너무 어렵습니다.. 구현된 코드를 보면서 하나씩 알아보면 좋을 것 같습니다ㅎㅎ 구현된 코드의 요구사항은 다음과 같습니다.
Transactional 어노테이션이 붙어있는 메서드가 호출된다면, 해당 메서드가 온전히 실행되면 commit, 예외가 발생하면 rollback 한다.
public class TransactionHandler implements InvocationHandler {
private final PlatformTransactionManager transactionManager;
private final AppUserService appUserService;
public TransactionHandler(PlatformTransactionManager transactionManager, AppUserService appUserService) {
this.transactionManager = transactionManager;
this.appUserService = appUserService;
}
@Override
public Object invoke(final Object proxy, final Method method, final Object[] args) throws Throwable {
Method realMethod = Arrays.stream(appUserService.getClass().getDeclaredMethods())
.filter(m -> compareTwoMethodSame(m, method))
.findAny()
.orElseThrow();
if (realMethod.isAnnotationPresent(Transactional.class)) {
final var transactionStatus = transactionManager.getTransaction(new DefaultTransactionDefinition());
try {
Object methodReturnValue = method.invoke(appUserService, args);
transactionManager.commit(transactionStatus);
return methodReturnValue;
} catch (Exception e1) {
transactionManager.rollback(transactionStatus);
throw new DataAccessException();
}
} else {
try {
return method.invoke(appUserService, args);
} catch (Exception e1) {
throw new DataAccessException();
}
}
}
private boolean compareTwoMethodSame(Method a, Method b) {
if (!a.getName().equals(b.getName())) {
return false;
}
Class<?>[] aParams = a.getParameterTypes();
Class<?>[] bParams = b.getParameterTypes();
if (aParams.length != bParams.length) {
return false;
}
for (int i = 0; i < aParams.length; i++) {
if (!aParams[i].getTypeName().equals(bParams[i].getTypeName())){
return false;
}
}
return true;
}
}
위 코드에서 중점이 되는 부분은 invoke 메서드입니다. 메소드가 호출되면, invoke()가 호출되며 전달받은 Method 객체를 사용하여 메서드를 호출하기 전, 후로 실행 로직을 처리할 수 있습니다. 실제 메소드가 호출되는 부분문 method.invoke() 입니다.
그렇다면 사용 측면에선 어떻게 사용하면 될까요? java.lang.reflect.Proxy 클래스의 newProxyInstance 메소드를 사용하여 프록시 객체를 만들어 줄 수 있습니다.
final var appUserService = new AppUserService(userDao, userHistoryDao);
final InvocationHandler invocationHandler = new TransactionHandler(platformTransactionManager, appUserService);
final UserService userService = (UserService) Proxy.newProxyInstance(
UserService.class.getClassLoader(),
new Class[]{UserService.class},
invocationHandler
);
주의할 점은, UserService는 인터페이스 타입입니다. Proxy의 newProxyInstance 메서드의 두번째 인자로 반드시 인터페이스 타입을 명시해 주어야 합니다. 자세한 사용 설명은 다음 사이트를 참고하시면 좋을 것 같습니다.
스프링의 빈을 기반으로 AOP 프록시를 만들어 주는 객체입니다. 3개의 역할이 필요합니다.
Advice
부가기능을 담고 있는 클래스입니다.
Pointcut
Advice가 적용될 조인 포인트를 선별합니다.
조인 포인트는 Advice가 적용 될 위치라고 생각하시면 됩니다.
Advisor
Pointcut과 Advice를 가지고 있는 객체입니다.
AOP의 Aspect와 같습니다.
Advice
public class TransactionAdvice implements MethodInterceptor {
private final PlatformTransactionManager transactionManager;
public TransactionAdvice(PlatformTransactionManager transactionManager) {
this.transactionManager = transactionManager;
}
@Override
public Object invoke(final MethodInvocation invocation) throws Throwable {
TransactionStatus transaction = transactionManager.getTransaction(new DefaultTransactionDefinition());
try {
Object methodReturnValue = invocation.proceed();
transactionManager.commit(transaction);
return methodReturnValue;
} catch (Exception e) {
transactionManager.rollback(transaction);
throw new DataAccessException();
}
}
}
Pointcut
public class TransactionPointcut extends StaticMethodMatcherPointcut {
@Override
public boolean matches(final Method method, final Class<?> targetClass) {
return method.isAnnotationPresent(Transactional.class);
}
}
Advisor
public class TransactionAdvisor implements PointcutAdvisor {
private final TransactionAdvice advice;
private final TransactionPointcut pointcut;
public TransactionAdvisor(TransactionAdvice advice, TransactionPointcut pointcut) {
this.pointcut = pointcut;
this.advice = advice;
}
@Override
public Pointcut getPointcut() {
return pointcut;
}
@Override
public Advice getAdvice() {
return advice;
}
@Override
public boolean isPerInstance() {
return true;
}
}
각각에 맞추어서 구현이 완료되었다면, 이제 ProxyBeanFactory 객체를 생성하여 설정해 주고 인스턴스를 생성하면 됩니다.
우선 프록시를 적용할 인스턴스와 Advisor을 미리 만들어 둡니다.
ProxyBeanFactory에 인스턴스와 Advisor을 넣어주고, getObject() 메서드로 프록시 객체를 얻어올 수 있습니다.
final ProxyFactoryBean proxyFactoryBean = new ProxyFactoryBean();
final UserService temporaryUserService = new UserService(userDao, userHistoryDao);
TransactionAdvice advice = new TransactionAdvice(platformTransactionManager);
final TransactionAdvisor advisor = new TransactionAdvisor(
advice,
new TransactionPointcut()
);
proxyFactoryBean.setTarget(temporaryUserService);
proxyFactoryBean.addAdvisor(advisor);
final UserService userService = (UserService) proxyFactoryBean.getObject();
DefaultAdvisorAutoProxyCreator
위 코드를 보면, 프록시 객체를 만들기 위해 많은 노력이 드는 것을 볼 수 있습니다. ProxyBeanFactory도 생성해야 하고.. Advice도 매번 만들어주어야 하고.. 인스턴스도 만들어주어야 하고..
이러한 부분들을 DefaultAdvisorAutoProxyCreator을 빈 등록만 해두면 쉽게 사용할 수 있습니다.
@Configuration
public class AopConfig {
@Bean
public TransactionAdvice transactionAdvice(PlatformTransactionManager platformTransactionManager) {
return new TransactionAdvice(platformTransactionManager);
}
@Bean
public TransactionPointcut transactionPointcut() {
return new TransactionPointcut();
}
@Bean
public TransactionAdvisor transactionAdvisor(TransactionAdvice advice, TransactionPointcut pointcut) {
return new TransactionAdvisor(advice, pointcut);
}
@Bean
public DefaultAdvisorAutoProxyCreator defaultAdvisorAutoProxyCreator() {
return new DefaultAdvisorAutoProxyCreator();
}
}
사실 이 부분은 이해가 잘 되지 않았습니다. 위의 ProxyFactoryBean은 명시적으로 프록시 객체를 만들어 주었거든요. 이 부분에서는 프록시 빈을 만드는 느낌은 아니었습니다.
이 부분은 찾아보니 빈 후처리기에서 동작하며 Advisors를 기반으로 AOP 프록시 객체를 만들어 준다고 합니다. 자세한 내용은 다음과 같습니다.
유저가 업로드한 프로필 이미지를 사용해야 하는데, 업로드된 이미지을 불러오는 기능을 어떻게 구현해야 할 까 해서 찾아보게 된 방식임. 대부분 정적 파일을 관리하는 또다른 서버를 둔다고 하지만 개발 단계에서의 이미지 업로드 / 이미지 표시를 해보아야 하므로 이미지 표시 기능을 따로 구현
아래 소스는 F('stories_filed') + 1 자체를 SQL Syntax로 만들어버려서 reporter.stories_filed의 값이 1 증가하는 쿼리가 실행된다. 이 때, reporter.stories_filed의 값을 갱신하는것이 아님. 데이터베이스 자체의 SQL문 실행
reporter.stories_filed 값을 실제 저장된 값으로 업데이트하기 위해선 모델을 데이터베이스에서 다시 불러와주어야 한다.
F Object는 save() 이후에도 모델에 남아있는 문제가 있으며, 각 save()에 적용된다. 따라서 초기 값이 1이라고 할 때, 처음 save 연산자를 해주면 SQL문이 실행되어 2가 되는데, 다음에 또 save 연산을 해주면 또 SQL문이 실행되어 3이 된다.이 과정을 해결해주기 위해서는 refresh_from_db()를 사용해주면 된다.
