request 스코프@Controller@RequiredArgsConstructorpublic class LogDemoController { private final LogDemoService logDemoService; private final MyLogger myLogger; @RequestMapping("log-demo") @ResponseBody public String logDemo(HttpServletRequest request) { String requestURL = request.getRequestURL().toString(); myLogger.setRequestURL(requestURL); myLogger.log("controller test"); logDem..
빈 스코프빈이 존재할 수 있는 범위싱글톤기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프프로토타입스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고더는 관리하지 않는 매우 짧은 범위의 스코프웹 관련 스코프request: 웹 요청이 들어오고 나갈때 까지 유지되는 스코프session: 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프application: 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프 프로토타입 스코프프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환한다요청 => 프로토타입 빈을 생성, 필요한 의존관계를 주입반환 => 생성한 프로토타입 빈을 클라이언트에 반환 / 같은 요청이 오면 항상 ..
스프링 빈의 이벤트 라이프사이클스프링 컨테이너 생성스프링 빈 생성의존관계 주입초기화 콜백 : 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출사용소멸전 콜백 : 빈이 소멸되기 직전에 호출스프링 종료의존관계 주입이 완료 되기 전에 초기화 작업을 하면 적용이 안됌@Bean 등록시 ~.setxx(xx) 이런거 해주면 안들어간다는 소리 @PostContruct / @PreDestroy()정상적으로 값 대입 후 출력 완료public class NetworkClient { private String url; public NetworkClient() { System.out.println("생성자 호출, url = " + url); } public void setUrl(String url) { this.u..
의존관계 주입생성자 주입생성자 호출 시점에 딱 1번만 호출 되는 것이 보장불변, 필수 의존관계에 사용final 키워드!!!!생성자에서 혹시라도 값이 설정되지 않는 오류를 컴파일 시점에 막아준다컴파일 오류는 세상에서 가장 빠르고 좋은 오류!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!@Componentpublic class OrderServiceImpl implements OrderService { private final UserRepository userRepository; private final DiscounPolicy discountPolicy; @Autowired public OrderServiceImpl(UserRepository userRe..
ComponentScan@Configuration@ComponentScan( basePackages = "hello.core", // 탐색할 패키지의 시작 위치를 지정 excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = Configuration.class)))public class AutoAppConfig {}// ex) filter로 Configuration을 걸면 @Configuration을 가지고 있는 다른 클래스들을 빼고 등록@ComponentRepositoryServiceRateDiscountPolicy...// @Component로 스캔할 대상을 등록함빈 이름 기본 전략: MemberServiceImpl 클래스 => member..
스프링 DI 컨테이너(싱글톤 컨테이너)스프링 컨테이너를 통해 사용자의 요청이 올 때 마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있게 됌 싱글톤 방식의 주의점여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지하게 설계하면 안됌무상태로 설계해야 함특정 클라이언트에 의존적인 필드가 있으면 안됌특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안됌가급적 읽기만 가능해야 함필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터 등을 사용해야 함스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있음public class StatefulService { private int price; // 상태를 유지하는 필드 ..