Enthusiasm! Enthusiasm!

타임리프의 특징 서버 사이드 HTML 렌더링(SSR) 타임리프는 백엔드 서버에서 HTML을 동적으로 렌더링 하는 용도로 사용된다. 네츄럴 템플릿 타임리프로 작성한 파일은 HTML을 유지하기 때문에 웹 브라우저에서 파일을 직접 열어도 내용을 확인할 수 있고, 서버를 통해 뷰 템플릿을 거치면 동적으로 변경된 결과를 확인할 수 있다. (JSP와 같은 다른 뷰 템플릿들은 서버를 통해 렌더링 된 이후에 정상적인 화면을 확인 할 수 있다.) 이와 같이 순수 HTML을 그대로 유지하면서 뷰 템플릿도 사용할 수 있는 타임리프의 특징을 네츄럴 템플릿이라 한다. 스프링 통합 지원 타임리프는 스프링과 자연스럽게 통합되고, 스프링의 다양한 기능을 편리하게 사용할 수 있게 지원한다. -위와 같이 html 문서에 선언하여 사용하..

HTTP 상태코드 이전 포스팅에서는 클라이언트에서 서버로 데이터를 요청하는 과정을 알아보았다. 클라이언트가 요청 시 서버는 응답 메시지를 생성하는데HTTP 상태코드란 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능이다. 상태코드의 종류 1xx (Informational): 요청이 수신되어 처리중 2xx (Successful): 요청 정상 처리 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함 알 수 없는 상태 코드 처리 : 클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면 클라이언트는 ..

HTTP(HyperText Transfer Protocol) HTTP는 HyperText Transfer Protocol의 약자로 웹 상에서 정보를 주고 받을 수 있는 프로토콜이다. HTTP의 기본 개념들과 특징을 알아보자. HTTP의 특징 HTTP 메시지(헤더+바디)에 모든것을 전송한다. HTML,TEXT,이미지,파일,API…등 서버간에 데이터를 주고 받을 때도 HTTP를 사용한다. 가장 많이 사용하는 버전은 HTTP/1.1이다. 현재 2,3도 나왔으며 2까지는 TCP, 3부터는 UDP를 사용한다. 클라이언트서버 구조 / 무상태 프로토콜(Stateless) / 비연결성 HTTP 메시지 / 단순하고 확장 가능하다. 무상태 프로토콜 서버가 클라이언트의 상태를 보존하지않는다. 서버의 확장성이 높으나 클라이언..

빈 스코프 스프링 빈이 기본적으로는 싱글톤으로 디자인되어있어, 컨테이너 생성과 함께 빈이 생성되고 종료 시 같이 종료된다. 하지만 스프링은 다음과 같은 다양한 스코프를 지원한다. 여기서 스코프는 빈의 생명주기라 생각하면 된다. 싱글톤: 기본 스코프. 컨테이너의 시작과 종료까지 유지 프로토타입: 스프링 컨테이너가 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 짧은 범위의 스코프 웹 관련 스코프 request: 웹 요청이 들어오고 나갈떄 까지 유지되는 스코프 session: 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프 application: 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프 @Scope(”prototype”)과 같이 사용한다. 프로토타입 스코프 싱글톤 스코프..

객체의 생성 및 초기화 데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면 객체의 초기화 및 종료 작업이 필요하다. 스프링이 이러한 초기화 작업과 종료 작업을 어떻게 진행하는지 알아보자 스프링 빈의 간단한 생명주기: 객체생성→의존관계 주입 스프링 빈은 객체를 생성하고, 의존 관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다. 따라서 초기화 작업은 의존관계 주입이 모두 완료되고 난 다음에 호출해야하고 개발자는 의존관계 주입이 완료된 시점을 알아야한다!!! → 스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능을 제..

조회 빈이 2개이상일때 현재까지는 같은 타입에 대해서 스프링 빈으로 등록할 클래스에만 @Component 애노테이션을 달아 컴포넌트 스캔에서 하나만 스캔이 되도록 하였다.만약 2개 이상의 빈을 컨테이너에 등록해두면, 타입으로만 조회하기 때문에 중복검색 오류가 발생한다. 이러한 문제를 해결하는 방법을 알아보자. @Autowired 필드명 매칭 (필드 명을 빈 이름으로 변경) -사용하고자하는 빈으로 필드명을 변경한다. -타입 매칭의 결과가 2개 이상일때 필드 명, 파라미터 명으로 이름을 매칭한다. Qualifier -빈 이름을 변경하지 않고 @Qualifier라는 추가 구분자를 붙혀주는 방법이다. -빈 등록시 Qualifier를 통해 지정한 이름으로 같은 타입의 빈을 구분한다. @Component @Qual..

의존관계 주입의 종류 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 생성자 주입 생성자를 통해서 의존관계를 주입 받는 방법, 생성자에 @Autowired 애노테이션을 붙혀주면 된다. 생성자 호출 시점에 딱 1번만 호출 되는 것이 보장된다. 불변, 필수의 의존관계에 사용 불변: 한번 의존관계가 주입되면 주입된 값이 프로그램 종료시까지 바뀌지 않음. 주입된 값이 바뀌어서는 안되는 상황일때. 사용, 외부에서 데이터에 접근할 수 없어야 하며, 반드시 생성자 주입으로 딱 한번만 주입 되어야 한다. 필수: private final과 같이 선언된 필드와 같이 반드시 값이 주입되어야 할 때 생성자 주입이 사용된다. 생성자가 1개만 있으면 @Autowired를 생략해도 자동으로 생성자 주입이 ..

컴포넌트 스캔 기초 기존에는 설정정보에 @Bean을 사용하여 일일이 스프링 빈을 등록했다. 이러한 방식은 누락의 위험, 번거로움이 동반되므로 스프링은 자동으로 스프링 빈을 등록하는 컴포넌트 스캔 기능을 제공한다. 컴포넌트 스캔을 사용하려면 @ComponentScan를 설정 정보에 붙여주면 된다. @Configuration @ComponentScan public class AutoAppConfig { } -기존의 AppConfig와 달리 컴포넌트 스캔을 사용하면, 객체를 생성하여 반환해주는 함수들이 필요없다. -의존관계 주입은 일반적으로 클래스 생성자에 @Autowired를 붙이는 생성자 주입을 사용한다. -컴포넌트 스캔은 이름 그대로 @Component 애노테이션이 붙은 클래스를 스캔해서 스프링 빈으로 ..

싱글톤 패턴(디자인) 스프링 전환 이전의 AppConfig를 다시 한번 살펴보자 -위 AppConfig의 문제점은 호출할때마다 새로운 객체를 생성하고 반환하고 있어, 동시에 여러 요청을 처리하는 프로그램에서는 객체가 수없이 많이 생성되어 서버가 이를 감당을 할 수 없게된다. -이러한 문제를 해결하기 위해, 같은 클래스에 대해서는 해당 객체를 한개만 생성하고 이를 공유하도록 설계하면 된다. 이와 같은 방법을 싱글톤패턴 이라 한다. Private 생성자를 이용하여 외부에서의 생성(new)를 제한한 아래 코드처럼, 순수 자바코드로 싱글톤 패턴을 설계할 수 있다. public class SingletonService { private static final SingletonServiceinstance= new ..

이제 컨테이너에 등록된 스프링 빈을 활용해보자. 스프링 빈을 활용하기 위해서는 먼저 스프링 빈을 조회해야한다. 컨테이너에 등록된 모든 빈 조회 AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); 모든 빈을 조회하기 위해서는 Beandefinition을 사용해야한다. 스프링 컨테이너를 ApplicationContext로 선언하면 Beandefinition을 사용할 수 없으므로 Beandefinition을 사용하기 위해서는 AnnotationConfigApplicationContext로 컨테이너를 선언해줘야 한다. String[] beanDefinitionNames = ac.getBean..