코드 그라데이션

스코프와 프록시 이번에는 프록시 방식을 사용해보자. [핵심 로직] @Component @Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS) public class MyLogger { } # proxyMode = ScopedProxyMode.TARGET_CLASS 가 핵심! 적용 대상이 인터페이스가 아닌 클래스면 TARGET_CLASS 를 선택 적용 대상이 인터페이스면 INTERFACES 를 선택 이렇게 하면 MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다. 그래서 전체 MyLogger @Component @Scope(value = "reques..

스코프와 Provider 앞선 포스팅에서 나온 에러를 잡는 방법을 살펴보자 LogDemoController 수정 @Controller @RequiredArgsConstructor public class LogDemoController { private final LogDemoService logDemoService; private final ObjectProvider myLoggerProvider; // 이것도 타입 바꿔줌 @RequestMapping("log-demo") @ResponseBody public String logDemo(HttpServletRequest request) { String requestURL = request.getRequestURL().toString(); MyLogger ..

build.gradle plugins { id 'java' id 'org.springframework.boot' version '2.7.16' id 'io.spring.dependency-management' version '1.0.15.RELEASE' } group = 'inflearn' version = '0.0.1-SNAPSHOT' java { sourceCompatibility = '11' } //lombok 설정 추가 시작 configurations { compileOnly { extendsFrom annotationProcessor } } repositories { mavenCentral() } dependencies { implementation 'org.springframework.boot..

웹 스코프 지금까지 싱글톤과 프로토타입 스코프를 학습했다. 싱글톤은 스프링 컨테이너의 시작과 끝까지 함께하는 매우 긴 스코프이고, 프로토타입은 생성과 의존관계 주입, 그리고 초기화까지만 진행하는 특별한 스코프이다. 이번에는 웹 스코프에 대해서 알아보겠다. 여기서는 request 스코프를 예제를 통해 구현해 나갈 것임. HTTP request 요청 당 각각 할당되는 request 스코프 => 동시에 요청이 들어와도 각각 할당된 인스턴스가 있어서 거기에 맞게 배당되어 일을 처리한다.

프로토타입 스코프 - 싱글톤 빈과 함께 사용시 Provider로 문제 해결 싱글톤 빈과 프로토타입 빈을 함께 사용할 때, 어떻게 하면 사용할 때 마다 항상 새로운 프로토타입 빈을 생성할 수 있을까? 스프링 컨테이너에 요청 가장 간단한 방법은 싱글톤 빈이 프로토타입을 사용할 때 마다 스프링 컨테이너에 새로 요청하는 것이다. 새로 받으면 됨. public class PrototypeProviderTest { @Test void providerTest() { AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(ClientBean.class, PrototypeBean.class); ClientBean clientBean1 ..

프로토타입 스코프 - 싱글톤 빈과 함께 사용시 문제점 스프링 컨테이너에 프로토타입 스코프의 빈을 요청하면 항상 새로운 객체 인스턴스를 생성해서 반환한다. 하지만 싱글톤 빈과 함께 사용할 때는 의도한 대로 잘 동작하지 않으므로 주의해야 한다. 그림과 코드로 먼저 보겠다. 먼저 스프링 컨테이너에 프로토타입 빈을 직접 요청하는 예제를 보자. 프로토타입 빈 직접 요청 스프링 컨테이너에 프로토타입 빈 직접 요청 1 스프링 컨테이너에 프로토타입 빈 직접 요청2 코드로 확인 SingletonWithPrototypeTest1 생성 package inflearn.spring_core.scope; import org.junit.jupiter.api.Test; import org.springframework.context...

프로토타입 스코프 싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환한다. 반면에 프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환한다. 싱글톤 빈 요청 1. 싱글톤 스코프의 빈을 스프링 컨테이너에 요청한다. 2. 스프링 컨테이너는 본인이 관리하는 스프링 빈을 반환한다. 3. 이후에 스프링 컨테이너에 같은 요청이 와도 같은 객체 인스턴스의 스프링 빈을 반환한다. 프로토타입 빈 요청 1 1. 프로토타입 스코프의 빈을 스프링 컨테이너에 요청한다. 2. 스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고, 필요한 의존관계를 주입한다. 프로토타입 빈 요청2 3. 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환한다..

빈 스코프란? 지금까지 우리는 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때까지 유지된다고 학습했다. 이것은 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문이다. 스코프는 번역 그대로 빈이 존재할 수 있는 범위를 뜻한다. 스프링은 다음과 같은 다양한 스코프를 지원한다. 빈 스코프는 다음과 같이 지정할 수 있다. 컴포넌트 스캔 자동 등록 @Scope("prototype") @Component public class HelloBean {} 수동 등록 @Scope("prototype") @Bean PrototypeBean HelloBean() { return new HelloBean(); } 지금까지 싱글톤 스코프를 계속 사용해보았으니, 프로토타입 스코프부터 확인해나가..