| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
- docker compose
- @ComponentScan
- 쿠버네티스
- Spring Data JPA
- 페이징
- Routing Key
- JPA
- CORS
- redis
- docker
- Dead Letter Queue
- 컨테이너
- MSA
- securitycontextholderfilter
- DI
- AWS
- mybatis
- JPQL
- 스프링 부트
- dockerhub
- kafka
- Spring Container
- JWT
- 지연 로딩
- Web
- Spring
- 서블릿 컨테이너
- @Transactional
- JdbcTemplate
- DLQ
- Today
- Total
목록Spring (80)
look-forest
스프링 MVC가 제공하는 기본 기능 중 HTTP 요청 관련 기능을 정리해보자 요청 매핑 1. 애노테이션 기반의 요청 매핑 //@RequestMapping 에 method 속성으로 HTTP 메서드를 지정하지 않으면 HTTP 메서드와 무관하게 호출 @RequestMapping(value = {"/hello-basic", "/hello-go"}, method = RequestMethod.GET) public String helloBasic() { return "ok"; } /** * 편리한 축약 애노테이션 * @GetMapping * @PostMapping * @PutMapping * @DeleteMapping * @PatchMapping */ @PostMapping(value = "/mapping-get")..
Spring MVC의 전체적인 구조와 핵심 동작 방식을 알아야, 향후 문제가 발생했을 때 대처가 가능하고, 확장 포인트가 필요할 때 감을 잡을 수 있다. 1. 전체 구조와 동작 순서 Spring MVC 전체 구조 동작 순서 프론트 컨트롤러가 핸들러를 찾아 어댑터로 실행하고, 반환 결과로 뷰를 렌더링한다. 핸들러 조회 : 핸들러 매핑을 통해 URL에 매핑된 핸들러(컨트롤러) 조회 어댑터 조회 : 핸들러를 실행할 수 있는 핸들러 어댑터 조회 어댑터 실행 : 프론트 컨트롤러(Dispatcher Servlet)에서 인터페이스(어탭터)를 통해 핸들러 실행 : 핸들러를 실행하고, 어댑터는 반환 정보를 프론트 컨트롤러에서 일괄 처리할 수 있는 ModelAndView 반환 : ModelAndView로 변환해서 반환한다..
이전에 빈의 생명주기에 따라 초기화, 소멸 콜백 메서드를 지정하는 방법을 알아보았다. 그렇다면 스프링 컨테이너가 관리하는 빈은 언제 생성돼서 언제 소멸될까? 빈 스코프란? 스프링 빈이 언제부터 언제까지 유지되는지, 유지 범위를 의미한다. 스프링은 다양한 스코프를 지원한다 싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다 프로토타입: 컨테이너가 프로토타입 빈의 생성과 의존관계 주입, 초기화까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프이다 웹 스코프 - request: 웹 요청이 들어오고 나갈때 까지 유지되는 스코프 - session: 웹 세션이 생성되고 종료될 때까지 유지되는 스코프 - application: 웹의 서블릿 컨텍스와 같은 범위로 유지..
객체의 초기화 작업과 종료 작업이 필요할 때가 있다. 예를 들어, 데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하고 리소스를 회수하는 작업이 있다. ※ 서버 띄울 때 미리 소켓을 열어놔야 클라이언트 요청에 빠르게 응답 가능 이러한 초기화 작업과 종료 작업을 스프링에서 어떻게 진행하는지 알아보겠다. 그냥 생성자에서 초기화 진행하면 되는거 아니야? 기본 전제 : 객체의 생성과 초기화를 분리하자 단일 책임의 원칙(SRP)과 같이, 역할을 분명히 나누는 것이 유지보수에 유리하다 생성과 초기화는 역할이 다르다. 생성자는 필수 정보를 받고, 메모리를 할당해서 객체를 생성하는 책임을 진다. 반면 초기화는 이렇게 생성된 값..
기본적으로 의존관계 자동 주입은 스프링 컨테이너가 관리하는 빈이어야 동작한다 이번 글에서는 다양한 의존관계 주입 방법과, 그중 어떤 방법을 어떻게 쓰면 좋은지에 대해 중점적으로 알아보겠다. 다양한 의존관계 주입 방법 의존관계 주입 방법은 4가지가 있다 생성자 주입 setter 주입 (수정자 주입) 필드 주입 일반 메서드 주입 1. 생성자 주입 필수 의존관계에 사용 - 생성자가 인자(의존관계)를 전달받아야만 객체가 생성되므로 불변 의존관계에 사용 - 생성자는 생성 시점에 딱 1번만 호출되는 것이 보장 - 생성자를 쓰면 final을 쓸 수 있다 생성자가 딱 1개만 있으면 @Autowired를 생략해도 된다 (여러 개면 어떤 생성자에 autowired 해줘야 할지 명확하지 않으니 지정해줘야 함) ※ final..
[수동 빈 등록 방식의 한계] 지금까지는 스프링 빈을 등록할 때 구성 정보를 설정 파일에 직접 명시해줬다. 자바 코드의 @Bean이나 XML의 등을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열했다. 이렇게 수동으로 등록해야 할 스프링 빈이 수십, 수백개가 되면 일일이 등록하기 번거롭고, 설정 정보도 커지고, 누락하는 문제도 발생한다. 그래서 스프링은 설정 정보가 없어도 자동으로 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다 컴포넌트 스캔과 의존관계 자동 주입 개요 1. 컴포넌트 스캔을 사용하려면 먼저 @ComponentScan을 설정 정보에 붙여줘야 한다 컴포넌트 스캔을 쓰더라도 빈을 수동 등록해도 된다 2. 빈으로 등록할 클래스에 @Component를 붙여주자 컴포넌트 스캔은 이름 그대로 @C..
순수한 DI 컨테이너인 AppConfig(설정 클래스)와 스프링 컨테이너의 차이는 무엇일까? 무엇이 차이를 만들어 내는 걸까? 더보기를 누르기 전에 생각해보자! Q. 웹 애플리케이션에서 싱글톤이 많이 쓰이는 이유는 뭘까? 더보기 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다 [문제] 이전에 만들었던 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청할 때마다 매번 객체를 새로 생성한다. → 메모리 낭비가 심하다! [해결] 객체를 1개만 생성해서 공유하도록 설계하면 된다 → 싱글톤 패턴 Singleton pattern 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴 구현 방법에는 여러가지가 있으나, 가장 기본적인 방법을 알아보자 Q. 기본적인 구현 방법? 더보기 1. s..
이번 시간에는 스프링 컨테이너와 빈의 생성 과정, 빈의 조회 과정에 대해 알아본다. 스프링 컨테이너의 생성 과정 Q. 스프링 컨테이너는 빈을 어떤 방식으로 저장하는가? 더보기 빈 이름을 key로 빈 객체를 value로 저장 빈 이름은 기본적으로 메소드 이름을 사용 Q. 스프링 빈 생성 과정에 필요한 정보는? 더보기 구성 정보 (XML, 자바 설정 클래스 등) 1. 스프링 컨테이너 생성 스프링 컨테이너: ApplicationContext (⊃BeanFactory) - ApplicationContext는 인터페이스 - AnnotationConfigApplicationContext는 구현체 스프링 컨테이너는 XML을 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다 스프링 컨테이너를..