HTTPHyperText Transfer Protocol모든 것이 HTTP - HTTP 메시지에 모든 것을 전송HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML (API) 거의 모든 형태의 데이터 전송 가능 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용 지금은 HTTP 시대! HTTP 역사HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X HTTP/1.0 1996년: 메서드, 헤더 추가 HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전 RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014) HTTP/2 2015년: 성능 개선 HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선 HTT..
전체 글
URIUniform: 리소스 식별하는 통일된 방식Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음) Identifier: 다른 항목과 구분하는데 필요한 정보 URL: Uniform Resource Locator URN: Uniform Resource Name 전체 문법 scheme://[userinfo@]host[:port][/path][?query][#fragment] https://www.google.com:443/search?q=hello&hl=ko프로토콜(https) 호스트명(http://www.google.com)포트 번호(443) 패스(/search) 쿼리 파라미터(q=hello&hl=ko) URL, URN URL - Locator: 리소스가 있는 위치를 지정 URN - N..
IP 인터넷 프로토콜 역할지정한 IP 주소(IP Address)에 데이터 전달 패킷(Packet)이라는 통신 단위로 데이터 전달 IP 프로토콜의 한계비연결성패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송 비신뢰성중간에 패킷이 사라지면? 패킷이 순서대로 안오면? 프로그램 구분같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면? JavaNetwork Repository에서 학습한 내용 TCP 특징전송 제어 프로토콜(Transmission Control Protocol) 연결지향 - TCP 3 way handshake (가상 연결) 데이터 전달 보증 순서 보장 신뢰할 수 있는 프로토콜 현재는 대부분 TCP 사용 UDP 특징사용자 데이터그램 프로토콜(User Datagram Pro..
웹 스코프웹 스코프는 웹 환경에서만 동작한다.웹 스코프는 프로토타입과 다르게 스프링이 해당 스코프의 종료시점까지 관리한다. 따라서 종료 메서드가 호출된다.requestHTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고 관리된다. sessionHTTP Session과 동일한 생명주기를 가지는 스코프application서블릿 컨텍스트( ServletContext )와 동일한 생명주기를 가지는 스코프websocket웹 소켓과 동일한 생명주기를 가지는 스코프 @Scope(value = "request")HTTP 요청 당 하나 씩 생성되고, HTTP 요청이 끝나는 시점에 소멸requestURL 은 이 빈이 생성되는 시점에는 알 수 없으므로, 외부에서 ..
스코프빈이 존재할 수 있는 범위싱글톤기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다.프로토타입스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프이다.웹 관련 스코프request : 웹 요청이 들어오고 나갈때 까지 유지되는 스코프이다.session : 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프이다.application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프이다. 컴포넌트 스캔 자동 / 수동 등록@Scope("prototype")@Componentpublic class HelloBean {}@Scope("prototype")@BeanPrototypeBean HelloBean() { r..
개발자가 의존관계 주입이 모두 완료된 시점을 아는 방법스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공 한다.스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 준다.따라서 안전하게 종료 작업을 진행할 수 있다. 스프링 빈의 이벤트 라이프사이클스프링 컨테이너 생성스프링 빈 생성의존관계 주입초기화 콜백사용소멸전 콜백스프링 종료 스프링은 빈 생명주기 콜백을 지원인터페이스(InitializingBean, DisposableBean)설정 정보에 초기화 메서드, 종료 메서드 지정@PostConstruct, @PreDestroy 애노테이션 지원 인터페이스InitializingBean 은 afterPropertiesSet() 메서드로 초기화를 지원한다..
생성자 주입 중요! 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입 된다. 물론 스프링 빈에만 해당한다@Componentpublic class OrderServiceImpl implements OrderService { private final MemberRepository memberRepository; private final DiscountPolicy discountPolicy; public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) { this.memberRepository = memberRepository; this.discountPolicy = discount..
@Configuration@ComponentScan( excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = Configuration.class) )public class AutoAppConfig { }컴포넌트 스캔은 이름 그대로 @Component 애노테이션이 붙은 클래스를 스캔해서 스프링 빈으로 등록한다. @ComponentScan 은 @Component 가 붙은 모든 클래스를 스프링 빈으로 등록한다.이때 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용한다.빈 이름 기본 전략: MemberServiceImpl 클래스 memberServiceImpl빈 이름 직접 지정: 만약 스프링 빈의 이름을 직접 지정하고 싶으..
스프링 컨테이너를 통해 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다. 싱글톤 방식의 주의점싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다싱글톤 패턴, 스프링 같은 싱글톤 컨테이너든 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문이다. 무상태(stateless)로 설계해야 한다특정 클라이언트에 의존적인 필드가 있으면 안된다특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다가급적 읽기만 가능해야 한다.필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다 @ConfigurationCGLIB 형식으로 반환한다코드 ..
빈 이름과 반환되는 객체 타입을 통해 등록한다.빈 이름은 항상 다른 이름을 부여해야 한다 (무시되거나 덮어버릴수 있음) 타입으로 조회시 같은 타입이 둘 이상 있으면, 중복 오류가 발생한다따라서 빈 이름을 지정해줘야 한다예) MemberRepository타입인 MemberRepository1, 2가 있으면타입으로 조회시 1, 2 가 조회 되므로 1 또는 2 의 빈 이름을 설정해주어야 한다. 부모 타입으로 조회시 자식이 둘 이상 있으면 중복 오류가 발생한다마찬가지로 빈 이름을 지정하면 된다 BeanFactory스프링 컨테이너의 최상위 인터페이스다.스프링 빈을 관리하고 조회하는 역할을 담당한다.getBean() 을 제공한다.지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능이다 Ap..
%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} -%kvp- %msg%n src/main/resources/logback.xml
제어의 역전 IoC(Inversion of Control)AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당하고 프로그램의 제어 흐름은 AppConfig가 가져간다.AppConfig는 OrderServiceImpl 이 아닌 OrderService 인터페이스의 다른 구현 객체를 생성하고 실행할수 있지만OrderServiceImpl은 자신의 로직을 실행한다.프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)이라 한다 프레임워크 vs 라이브러리프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다. (JUnit)반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리다. 의..