제리 devlog

스프링은 JDK Dynamic Proxy, CGLIB의 프록시 생성 패턴을 사용한다. 이전 글에서 소개한 것 처럼 JDK Dynamic Proxy는 리플렉션을 사용하며 인터페이스가 반드시 필요했다. 반면, CGLIB는 바이트 코드를 조작해서 프록시를 만들고 상속을 사용하기 때문에 구체 클래스만으로도 프록시 생성이 가능했다. 하지만, 매번 코드상의 인터페이스 유무를 확인해서 JDK Dynamic Proxy의 InvocationHandler, CGLIB의 MethodInterceptor를 구현하기 쉽지 않다. 또한, 프록시 로직이 같을 때 인터페이스 유무가 다르다면 같은 내용의 InvocationHandler, MethodInterceptor를 작성해야 한다. 꽤 번거롭다. 스프링의 프록시 팩토리는 프록시 ..

프록시는 접근 제어, 값 변형을 사용하는데 유용한 패턴이다. 하지만, 특정 클래스마다 프록시 클래스를 만들어 작업하기에는 너무 고되다. 자바에서 기본적으로 제공하는 프록시 생성 오픈 소스를 사용하면 동적으로 프록시를 생성할 수 있다. JDK Dynamic proxy는 인터페이스를 기반으로, CGLIB는 상속을 기반으로 프록시를 생성한다. 이 두가지 방식은 모두 스프링에서 프록시를 만드는데 사용하는 기술이다. 우선, 프록시가 인터페이스, 상속 기반으로 어떻게 만들어지는지 잘 모른다면 아래 게시글을 먼저 참고하자! https://jgrammer.tistory.com/entry/%ED%94%84%EB%A1%9D%EC%8B%9C%EB%A5%BC-%EB%A7%8C%EB%93%9C%EB%8A%94-%EB%B0%A9..

spring boot에서 동적으로 프록시를 만드는데 사용되는 jdk 동적 프록시, cglib방식을 정리하기 전 프록시를 만들 수 있는 방법에 대해서 알아보자. 프록시를 만드는 방식은 인터페이스 기반 방식과 클래스 상속 기반 방식이 있다. 인터페이스 기반 프록시 생성 인터페이스 기반 프록시 생성은 실제 클래스와 프록시 클래스가 동일한 인터페이스를 구현한다. interface Subject { fun operation(): String } 실제 클래스와 프록시 클래스는 각각 이 인터페이스를 구현해야 한다. class ReadSubject : Subject { private val logger = LoggerFactory.getLogger(this::class.simpleName) override fun op..

콜백이란? 프로그래밍에서 콜백(callback) 또는 콜 애프터 함수(call-after function)는 다른 코드의 인수로서 넘겨주는 실행 가능한 코드를 말한다. 콜백을 넘겨받는 코드는 이 콜백을 필요에 따라 즉시 실행할 수도 있고, 아니면 나중에 실행할 수도 있다. (위키백과 참고) callback은 코드가 호출은 되는데 코드를 넘겨준 곳의 뒤에서 실행된다는 의미이다. 템플릿 콜백 패턴이란? GOF의 디자인 패턴은 아니다. 전략 패턴에 특정 방식을 사용하는데 스프링 내부에서 이런 방식이 자주 사용되기 때문에, 스프링에서는 이렇게 부른다. 스프링에서는 JdbcTemplate, RestTemplate , TransactionTemplate , RedisTemplate 처럼 다양한 템플릿 콜백 패턴이 ..

서버를 운영하다 보면 hikari connection과 관련된 에러를 겪게 된다. 은근히 놓치기 쉽고 빈번하게 발생 가능한 부분이라 정리를 해보려고 한다. connection 관련 문제는 보통 아래의 에러 메시지와 함께 문제가 발생한다. - org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction - Unable to acquire JDBC Connection - HikariPool-1 - Connection is not available, request timed out after 3005ms. - o.h.engine.jdbc.spi.SqlException..

Spring 프레임 워크에서 제공하는 캐시는 추상화가 잘되어있고 여러 어노테이션(@Cacheable, @CacheEvict..)을 사용해서 간단히 사용하기 편하다. 다만, 내가 redis를 구현체로 사용하면서 느꼈던 불편함은 캐시의 만료시간을 설정하기 까다롭다는 점이다. 우선, spring에서 제공하는 @Cacheable, @CachePut 등의 어노테이션으로는 만료시간을 설정하는 옵션이 없다. 기본적으로는 만료 시간이 없게 캐시가 저장되기때문에 필요하다면 캐시를 명시적으로 제거해주거나 업데이트해줘야 한다. 만료 시간만 설정되면 되는데 캐시를 컨트롤해줘야 하는 로직이 불필요하게 코드 안에 섞이는 건 부담스러웠다. 그렇다고 만료기간을 설정할 방법이 없는 건 아니다. 첫 번째 방법으로, cachemanger..

얼마전까지 의존성 주입에 @Autowired방식을 맹목적으로 사용해왔다. 다른 방식이 있는 줄은 모르고 어노테이션을 사용하면 의존성 주입이 간편해서 이런 방식으로 해왔다. 그러다 우연히 의존성 주입은 생성자를 사용한 방식이 좋다는 글을 몇차례 접한뒤 좋은 이유에 대해서 알아보고 실제로 적용해보기로 했다. 의존성 주입 3가지의 방식 첫번째, Field Injection Field Injection은 의존성을 주입하고 싶은 필드에 @Autowired 어노테이션을 붙여주면 의존성이 주입된다. @RestController public class PostController { @Autowired private PostService postService; } 두번째, Setter based Injection set..