프랑스얼음왕자

Transport layer 에서의 가장 핵심적인 키워드는 바로 바로~~ 프로세스와 프로세스간의 연결이었다. 친구랑 나랑 카톡할 때 내가 보낸 카톡 메시지가 상대방에게 문자 메시지로 가는게 아닌 카톡 메시지로 가게끔 하는 것이 이 계층이었다. 그렇다면 network layer는 무엇일까? 고것은 바로 두 호스트간을 연결해준다. 내가 친구 A에게 보낸 카톡이 엄마 핸드폰이 아닌 친구 핸드폰으로 보내는 것과 같다고 생각하면 된다. 정리하자면 network layer를 통해 누구에게 보내는지 명시하고 tranport layer를 통해 상대방이 다루고 있는 여러 프로세스 중 어느 프로세스에게 보낼지 정하고 application layer는 내가 보낸 메시지를 선택된 프로세스를 통해 어떠한 모습으로 보여주는지, ..

빈 스코프 1편에 이어서 빈 스코프 2편으로 돌아왔습니다!!!! 1. 싱글톤 빈이 프로토타입 빈을 의존한다면..? 만약에 clientBean이라는 싱글톤인 빈이 있다면, 컨테이너의 생성과 동시에 clientBean을 만들고 이것이 의존하는 프로토타입 빈이 있다면 의존관계 자동주입을 하게 되면서 컨테이너에 이 프로토타입 빈을 요청한다. 그러면 컨테이너는 이를 반환하고 clientBean은 이 프로토타입 빈을 보관한다. 포함한다고 생각하면 된다. 아래 그림처럼. 이제 이렇게 되면 싱글톤이 프로토타입 빈을 품고 있기에 이 프로토타입 빈은 싱글톤과 함께 컨테이너 종료 시까지 계속 살아있는 것이다. 즉, 첫번째 손님이 와서 count++를 하여 1을 늘리고 튀어 버리면 두번째 손님이 count++를 또 하게 되면..

오늘 포스트는 빈의 생존능력에 대해 알아 보올 거시다! 게다가 빈도 이 생존능력에 따라 두 가지 버전이 있다느은 거시다! 생존능력은 사실 빈이 얼마나 잘 사는 지가 아니라아 스프링 컨테이너가 얼마나 오래 가지고 있어주냐는 거시다! 거두절미하고 빈 생명주기를 시작으로 오늘 포스트를 시작할 거시올시다! 1. 빈 생명주기 애플리케이션이 시작하고 종료할 때 스프링 빈들 또한 생성되고 초기화하고 사라져야야 한다. 이 과정들에 대해 다루어 보자. 스프링 빈은 저번에도 주구장창 이야기 하였는데, 빈의 생성 단계는 객체를 생성하고 의존관계를 주입하는 두 단계의 라이프 사이클을 가진다. 당연히 이 두 단계를 지나야지만이 초기화 작업들을 할 수 있다. 그렇다면 우린 초기화 작업을 해야하는데 할 수 있는 지 없는 지 아는 ..

오느르은 저번에 다룬 의존관계 자동주입과 관련하여 여러 디테일들에 대해 다루어 보겠다. 1. 조회한 빈이 2개 이상 예를 들어 A라는 인터페이스를 상속받은 a,b가 있는데 기존에는 a와 b 둘 중 하나만 @Bean을 사용하던지 @Component을 사용해서 의존관계를 설정해 주었다. 하지만 만약 a,b 둘 다 스프링 컨테이너에 등록 되어 있다면..? 둘 중 하나를 지우면 되겠지만,, 어떤 상황에는 a가 필요하고 다른 상황에는 b가 필요하다고 하면,, 곤란하다. 물론 @Congfiguration 어노테이션을 붙인 두 Config 클래스를 만들면 되겠지만, a와 b말고 모두 다 같다면 복붙하기만 하면 되지만,,, ㅋㅋㅋㅋㅋ 우리 좀 간지나게 살아보자. 이 간지나는 삶을 위해 스프링이 제공하는 방식 3가지가 ..

딱히 정리하면서 쓸 만한 건 아니고 룸복이 상당히 편해보이고 좋아 보여서 다음에 룸복을 사용하게 될 때 필요한 설정들을 다루고자 적는다. 항상 start.spring.io 에서 프로젝트 만들 때 lombok 라이브러리를 체크해서 넣어두자! 깜빡했다면 구글링해~ ㅋㅋㅋ(이 글 왜씀) 약간 인성 안 좋아 보일 수 있으니 귀찮지만,,, build.gradle에 들어가서 다음 문구들을 복붙한다. (다시 말하지만 그냥 프로젝트 만들때 까먹지말고 룸복 라이브러리를 넣어라~ 지금 이건 안넣었을 경우!) lombok 설정 추가 시작 configurations { compileOnly { extendsFrom annotationProcessor } } //lombok 설정 추가 끝 dependencies{ ... //l..

지난 시간에 간단하게 의존관계 자동 주입에 대한 언급을 살짝 했다. 요번엔~~~ 이 의존관계 주입에 대해서 세세히 알아보자! 의존관계 주입은 크게 4가지의 방법이 있다. 생성자 주입(이건 계속 해오던 것!), 수정자 주입(setter 주입), 필드 주입, 일반 메서드 주입. 차례로 뿌셔보자!(사실 간단하다 ㅎㅎ) 1. 생성자 주입 이름 그대로 생성자를 통해서 의존관계를 주입한다. 우리가 자주 해오던 것. 생성자 호출 시점에 딱 한번만 하기에 이후에 변경할 수 없다는 것이다. 안좋아 보이지만 말을 바꾸어보면 바꿀 염려가 없으니 의존관계를 처음에만 잘 하면 상당히 안전하다는 것을 알 수 있다. @Autowired public OrderServiceImpl(MemberRepository memberReposi..

이번 글은 꽤 짧을 것 같다. 왜냐면 내가 짧게 쓸 꺼니깐 ㅎㅎ. 컴포넌트 스캔이 저번에 배운 자바 빈을 다르게 설정하는 거기 때문에 개념위주 보단 코딩 시 유의점 같은 부가적인 이야기를 할 것 같다. 1. 컴포넌트 스캔 저번에 배운 스프링 빈으로 일일이 등록하기란 생각보다 귀찮을 수 있다. 그래서 한번에 쫘악 긁어 모아 스프링 빈으로서 스프링 컨테이너에 등록하는 방법인 컴포넌트 스캔이 있다. 그리고 다음 글에서 엄청엄청 자세히 다룰 의존관계 자동주입(@Autowired)에 대해 배울 거지만 여기서 소개해야 겠다. 말 그대로 기존에는 생성자 주입을 통해 의존관계를 설정 했다면 이젠 그딴 거 필요 없다. 바로 위 어노테이션이 알아서 해준다.. 밑에서 말하겠당! 2. In Code @Configuration..

웹 어플리케이션은 대게 한번에 여러 요청이 들어오게 된다. 이때 클라이언트와 관계 없는 획일화 된 서비스를 제공 한다고 하자. 이럴 때 마다 서비스 객체를 계속 새로 만들어서 제공하는 것은 정말 멍청한 짓이지 않을 까? 그래서 이러한 서비스들에 대해 딱 하나의 객체만 만들어서 모든 클라이언트에게 제공하도록 하는 개념이 싱글톤 패턴이다. 오늘은 이것에 대해 알아보자 !@! 1. 순수 자바 코드로 싱글톤을 만들어 보기 SingletonService라는 객체가 있다고 하면 단순히 생성자 함수를 private으로 선언하면 된다. 그 외에도 몇 가지 추가 설정이 필요한데 코드로 보여줄께요~ public class SingletonService { //static을 붙이면 class level에 올라가서 하나의 인..

01에서는 application layer를 배워보았다. 생각해 보면 사용자와 밀접하게 연관되어 있어 최종 결재자 느낌이다. 또한 application layer에 여러개의 프로세스가 socket이라는 문과 함께 떠있고 port 번호를 통해 구분이 된다고 했다. 그렇다면 자연스럽게 transport layer의 역할 중 하나가 port번호에 맞는 socket을 찾게 도와주는 역할! 오오오 드디어 연결 되었다. 그래서 이번 글은 방금 같은 분류 역할과 UDP와 TCP, TCP의 부가 기능들, 데이터 송수신 규약들을 이야기 해보겠다. 레고~ 앗 참고로 4계층에서는 선물포장지를 segment라 하기로 한 점 잘 기억하기 바란다. 1. UDP와 TCP의 비교 사실 저번 글 부터 근근히 많은 예시를 들었다. 그래..

00 부분에서 전반적인 이야기를 잘 다루었으니 이제 하나씩 하나씩 이야기를 해보자! 저번에 이야기 했듯이 컴퓨터에는 여러 어플들이 동시에 돌아가고 있다는 사실! 그리고 이 어플들을 프로세스라고 한다. 계산기 어플이 있을 때 1+1 과 2+2 는 다른 결과를 낸다. 같은 어플이라도 인풋 값이 바뀌거나 조그마한 설정 하나만 다르게 되면 다른 프로세스라고 보면 된다. 물론 1+1을 두 번 하면 같은 프로세스? 아뇨아뇨 다른 프로세스. 그니깐 어플은 실행 틀이고 실제 실행 중인 것을 프로세스라고 생각하면 된다. 마치 클래스와 객체 관계처럼.. 아무튼 이 이야기를 왜 했을까? 눈치 챘다면, 프로세스가 바로 application layer의 산물이라 생각하면 된다. 참고로 프로토콜은 대화 방식 규약이라고 생각하라...