
Random Port의 SpringBoot 테스트를 진행할 때 Transactional이 적용되지 않는 문제를 직면하여 이유를 간단히 알아보았습니다. 잘못된 내용이 있다면 지적 부탁드립니다. @SpringBootTest의 Web Environment SpringBootTest의 Web Environment 설정은 네 가지가 있다. 기본값인 MOCK은 mocking 된 서블릿(WebApplicationContext)을 로드하며 NONE의 경우는 서블릿 환경을 아예 제공하지 않는다. 반면 RANDOM_PORT 혹은 DEFINED_PORT 옵션을 사용하면 각각 임의의, 혹은 지정된 포트로의 실제 서블릿 환경(EmbeddedWebApplicationContext)을 로드한다. 이로 인해 RANDOM_PORT 혹..

필드 주입도 순환 참조를 검사해 준다? 스프링의 의존성 주입과 관련하여 코드를 작성해 보던 중, 필드 주입 또한 순환 참조를 검사해 주는 것을 확인하여 의문이 생겼다. 기존에 생성자 주입을 권장하는 이유는 빈의 생명주기 중 처음 두 단계 중 1번의 인스턴스 생성을 위한 생성자 호출에서 바로 의존성을 주입해야 하므로 순환 참조를 찾을 수밖에 없기 때문으로 이해했다. 빈 객체의 인스턴스 생성 단계 의존성 주입 단계 @PostConstruct나 InitializingBean 인터페이스의 구현 메서드에 의한 초기화 단계 스프링 컨테이너 종료 시 @PreDistroy나 DisposableBean 인터페이스의 구현 메서드에 의한 소멸 단계 이번에 새로 경험한 것은 생성자 주입이 아닌 필드 주입과 같은 방법으로 빈을..

목차 1. @Autowired 어노테이션 2. @Autowired를 통한 의존성 주입 방법 3. 생성자 주입을 사용하는 이유 4. @Primary 혹은 @Qualifier를 통해 주입될 구현체 명시하기 @Autowired 어노테이션 스프링 컨테이너에 어노테이션을 통해 빈을 등록하는 방법은 크게 두 가지다. @Bean 어노테이션을 통한 빈 등록 (메서드 레벨) @Component 어노테이션을 통한 빈 등록 (클래스 레벨) @Bean의 경우 메서드에 붙여 해당 메서드를 통해 반환되는 객체를 Bean으로 관리할 때 사용한다. 이와 달리 @Component는 클래스에 붙여 해당 클래스 타입을 기반으로 빈을 관리하도록 한다. @Repository, @Service, @Controller 등의 어노테이션들은 @Co..

Stack을 쓰지 말라 프로그래밍에 조금만 익숙하다면 Stack과 Queue라는 자료구조를 알 것이다. 각각 LIFO(Last In First Out), FIFO(First In First Out)가 필요한 상황에 흔히 사용된다. java.util의 Stack은 Vector를 상속받아 구현되었는데 Vector는 대표적인 자바의 레거시 클래스로 Stack 또한 이 단점을 그대로 가지고 있다. A more complete and consistent set of LIFO stack operations is provided by the Deque interface and its implementations, which should be used in preference to this class. For exam..

try-finally의 단점 InputStream, OutputStream과 java.sql.Connection과 같은 자원은 close 메서드를 사용자가 직접 호출해 닫아주어야 한다. 이런 자원을 직접 닫아주지 않아도 gc가 알아서 처리해주긴 하지만 그 시점을 정확히 알 수 없기 때문에 직접 닫아주는 것이 가장 안전하다. Java7 이전에는 자원의 닫힘을 처리하기 위해 try-finally가 사용되었다. BufferedReader를 사용해 한 줄의 콘솔 입력을 받는 메서드는 아래와 같다. String readLine() throws IOException { BufferedReader br = new BufferedReader(new InputStreamReader(System.in)); try { re..

동일성과 동등성 '동일하다'와 '동등하다'는 거의 같은 단어처럼 들리겠지만 프로그래밍에서는 큰 차이를 가지고 있다. int나 double 같은 기본 타입의 경우 우리는 '==' 연산자를 통해 같음을 확인한다. 그러나 객체의 경우 우리가 같다고 취급하고 싶어도 equals 메서드 혹은 '==' 연산자로 동일함이 확인되지 않는다. System.out.println(1 == 1); // true // 리터럴로 생성된 string은 string pool에 담겨 같은 객체가 재사용된다. String string1 = "string"; String string2 = "string"; System.out.println(string1 == string2); // true System.out.println(string1..
- Total
- Today
- Yesterday
- JPA
- MySQL
- Fromtail
- invokedynamic
- 스프링
- Payload 암호화
- springboottest
- GitHub Discussion
- logback-spring.xml
- 함수형 인터페이스
- Java
- RandomPort
- 생성자 주입
- 람다식
- Spring Boot Monitoring
- 의존성 주입
- multiplebagsfetchexception
- stubbing
- GitHub Discussion 템플릿
- Jenkins 예약 배포
- 우테코
- Spring 테스트
- GitHub Discussion Template
- Spring
- 우테코 5기
- java switch case
- MySQL 이벤트 스케줄
- 우테코 프리코스
- 자바
- JPA JSON
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |