
Spring 에서 제공하는 http client로는 대표적으로 RestTemplate이 있다. 이 RestTemplate으로 http 요청을 날리게되면 기본적으로 그때마다 connection을 맺고 응답을 받으면 끊게된다. 이를 db connection pool 처럼 connection pool을 만들어서 관리할 수 있다. 이를 설정하기위해서는 일단 RestTemplate에 대해서 먼저 이해를 해야하는데 Spring 에서 제공하는 RestTemplate은 직접 http 요청을 하는 역할을 수행하지않는다. 직접 수행하는 클래스를 한번 래핑한 어댑터 역할을 하는 클래스이다. 기본적으로는 jdk에서 제공하는 HttpUrlConnection 클래스를 이용한다. 우리는 apache 에서 제공하는 HttpClien..
두번째 포스팅을 할지말지 확신이 안섰는데 어느정도 삽질을 통해 알게된점들이 있어서 두번째 포스팅을 한다. spring boot에 적용하기라는 제목치고는 앞선 포스팅에서 spring boot 관련 얘기가 하나도 없어서 이에 관한 내용도 적으려한다. 일단 기본적인 구성은 앞 포스팅에서 다 진행됐다. 간략한 테스트를 진행해보자. jooq API를 사용할때는 DSLContext 객체를 이용하게되는데 이 객체는 spring boot 자동구성에 의해 spring bean으로 등록된다. 편하게 주입받아서 사용하면된다. 우리가 설정해줘야할것은 datasource 관련 설정만 해주면된다. spring: datasource: driver-class-name: org.sqlite.JDBC url: jdbc:sqlite::r..
신규 프로젝트에 DB access를 어떤 프레임워크를 사용할까 고민을 해봤다. 일단 난 MyBatis만 사용해와서 이번에 다른 프레임워크를 사용해보고싶은 마음이 있었다. 후보군은 이렇다. JPA JdbcTemplate MyBatis jooq 아직 실무에서 JPA 경험이 없는터라 JPA를 사용할까도 생각해봤지만 팀 구성원에 JPA에 경험이 있는 사람이 없고, 다른 기술셋들도 생소한걸 사용하기로해서 패러다임 자체를 바꿔야하는 JPA는 좀 무리라고 생각했다. 서비스 구성이 readonly라서 select만 필요한것도 JPA를 욕심내지않는것에 한몫하기도했다. 그러던중 jooq 라는 프레임워크가 있는걸 알게되어 도입을 고민해보게됐다. 각 기술에 대한 결정을 하게된 배경은 이렇다. JPA JPA에 대한 내용은 위에..
오늘은 Spring Cloud Hystrix 에 대해서 포스팅하려한다. 넷플릭스에서 Hystrix 를 만들어서 공개했는데 이를 좀 더 스프링 친화적으로 스프링에서 래핑해놓았다. Hystrix는 Circuit Breaker 패턴을 적용하여 서비스를 제공하는 Supplier에 장애가 생겼을때 Supplier를 호출하는 Consumer까지 장애가 전파되지않도록 Circuit Breaker 를 오픈하는 방식의 라이브러리이다. 외부 API를 호출하는 경우가 있다면 장애전파를 막고자할때 유용하게 사용할 수 있다. 이번 포스팅에서 작성할 애플리케이션은 Supplier, Consumer와 모니터링에 사용할 Dashboard, 그리고 여러 인스턴스를 모아서 모니터링할때 필요한 Eureka와 Turbine까지 총 5개다...
Spring Cloud Config Client지난 포스팅에서 config server를 띄우는것 까지 진행했다. 이제 config server가 구동되고있는 상태에서 그 정보들을 받아올 client 를 구현해보자. config 를 제대로 받아오는지 확인하는 용도의 스프링 부트 웹 애플리케이션을 만들면된다. 아래 의존성을 넣어주면 된다. implementation('org.springframework.boot:spring-boot-starter-web') implementation('org.springframework.cloud:spring-cloud-starter-config') 그리고 아무것도 하지않고 서버를 띄워보자. 8080으로는 이미 config server가 사용되고있으니 아래설정을 넣어주고 ..
보통 스프링 부트 애플리케이션을 만들다보면 설정파일은 properties나 yml 파일로 추출해서 관리하게된다. profile 별로 파일을 분리까지하게되면 그 자체로 훌륭하게 설정을 분리해냈다고 할 수 있다. 하지만 여전히 존재하는 문제중 하나는 설정만 바뀌었음에도 빌드를 다시하고, 배포를 다시해야한다는 점이다. 나같은 경우는 AB 테스트를 진행하게됐고, AB의 비율을 자주 변경해야하는 이슈가 있었는데, 이를 기존대로 설정파일 분리만 해놓을 경우 비율을 바꿀때마다 릴리즈 배포를 해야했다. Spring Cloud Config 는 별도 config 서버를 두고 애플리케이션이 해당 서버에서 설정을 받아오는 방식이다. 중간에 설정이 바뀌는 일이 발생하면 config 서버만 변경해주고 애플리케이션은 설정을 갱신하..
spring cloud config client를 사용하여 갱신된 config 정보를 받아오기위해선 /actuator/refresh 를 호출해야한다. 그런데 이때 전혀 신경도 쓰지않았던 Hikari 에서 예외가 발생하는 경우가 있다. java.lang.IllegalStateException: The configuration of the pool is sealed once started. Use HikariConfigMXBean for runtime changes. 이런 에러메세지가 나오는데 정확히 파본건 아니지만 refresh 를 하면서 config들을 갱신할때 Hikari 쪽을 호출하는듯 하다. 이것도 확인해본건 아니지만 아래처럼 @ConfigurationProperties 애노테이션을 사용해서 생성할..
소스 레벨 애노테이션을 정의하고 컴파일을 할때 아래와 같은 에러가 발생했다.. javac -processor processor compileJava 명령어를 치니까.. error: Could not instantiate an instance of processor 'com.yong.java10.AnnotationProcessor' 1 error 왜 안되는건지 정말 오랜시간 탐구했는데....내가 processor 클래스의 접근제어자를 default 로 해놨었다 ㅡㅡ;;IDE가 만들어주는대로 썼으면 public이 붙어있었을텐데 다른데서 작성하고 복붙하다가.... 이것때문에 주말 몇시간 날렸다.
스프링에서 AOP를 구현하는 방법중 하나가 dynamic proxy 를 이용하는 방법이다. 특별한 내용은 아니고, dynamic proxy 를 직접 구현해보는 포스팅을 하나 하고자한다. public interface Inter { String toMessage(); } 먼저 인터페이스를 하나 정의해준다. 예제를 위한 인터페이스라 대충 만들었다. 이제 proxy 를 구현해주자. Proxy 클래스에있는 팩토리메서드를 호출하면 된다. public static Object newProxyInstance(ClassLoader loader, Class[] interfaces, InvocationHandler h)(호출해야할 메서드) 파라미터들을 확인해보자. 클래스로더와 구현해야할 인터페이스, 그리고 호출핸들러를 필..
- Total
- Today
- Yesterday
- TEST
- DesignPattern
- clean code
- toby
- http
- code
- JavaScript Core
- java
- generics
- EffectiveJava
- go-core
- backend개발환경
- frontend개발환경
- frontcode
- Spring
- 정규표현식
- Kotlin
- javascript
- Git
- mariadb
- Jackson
- spring cloud
- MySQL
- OOP
- Design Pattern
- db
- JPA
- java8
- programming
- servlet
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |