@Configuration은 해당 클래스가 설정에 관한 클래스임을 Spring Container에게 알리고, 그것을 Bean으로 등록하도록 하는 어노테이션이다. 어? 그러면 해당 클래스가 설정 파일임을 가시적으로 알리는 일 외에는 @Bean과 똑같은 것인가? 물론 아니다. 설정 파일의 경우, 해당 설정의 통일성을 위해서 하나만 생성하고, 프로젝트 내에서 계속 그 내용을 재활용하며 써야한다. 이에 상응하여 @Configuration이란 어노테이션은 클래스를 Bean으로 등록하고 해당 Bean 객체를 싱글톤이 되도록 설정해준다.

스프링에서 제공하는 HTTP Client REST API 호출에 필요한 함수를 제공하는 클래스이다. HTTP Client Rest API란? 먼저 웹이 어떻게 돌아가는지 살펴봐야한다. 웹은 클라이언트와 서버로 나뉜다. 클라이언트 부분은 사용자에게 필요한 정보를 서버에게 요청하고, 서버는 그에 맞는 데이터를 클라이언트에게 제공한다. 해당 과정에서 클라이언트가 서버에게 원하는 정보를 요청하는 부분을 HTTP Client REST API라고 한다. 우리가 사용하려는 SPRING은 백엔드 프레임워크로 서버의 역할을 담당하는 경우가 많지만, 때에 따라서 외부 API에게 데이터를 요청해야하는 클라이언트의 역할을 해야할 수도 있다. 원래 JAVA에서는 URLConnect나 HTTPClient 같은 클래스를 사용하여 ..

Beans가 무엇인지 알아본다. Application Context가 무엇인지 어떻게 돌아가는지 그 원리, 종류에 대해서도 알아본다. 1. Beans란? (1) Beans의 역사 처음에 Java의 개발진인 SUNS에서 JavaBeans를 발표했다. JavaBeans는 재사용이 가능한 컴포넌트를 말한다. Beans는 Client 측면 (Front-end), 서버 측면 (Back-end) 각각 나뉘어서 쓰였다. 원래 개발진들은 Beans가 Client GUI에서 많이 사용되길 바랬다. 예를 들어 검색창을 누가 만들어 놓으면 누군가 그것을 재사용하도록 하는 것이다. 근데 Clinet GUI 파트에서의 Beans는 내용이 너무 복잡해서, 사람들이 아무도 쓰지 않아 망했다. 되려 서버 측면에서 Beans가 각광받..

0. 지금까지 한 것들 지금까지는 DI라는 컴퓨터 본체의 내부를 뜯어 봤다. Main1은 Di의 개념: 외부에서 객체를 생성해서 소스코드 내부로 주입한다는 게 어떤 의미인지 알아보았다. Config.txt라는 문서에 객체이름 = "해당 객체 구현하는 클래스의 경로주소" 로 값들을 저장해놓는다. 그러면 Main1 내부의 함수가 문서 내용을 받아와서, 경로주소를 ReflectionApi를 이용해 메타데이터로 진짜 객체를 만들어서 반환한다. 우리는 new 선언 없이 해당 매소드만을 이용해 객체 생성이 가능해졌다. Main2는 객체 저장소라는 개념을 소개 했고 그것이 어떻게 돌아가는지 로직을 설명했다. 객체 저장소는 Config.txt의 내용을 Map 형태로 일단 받아온다. 그러면 Key는 객체이름, Value..

저번 시간에 배웠던 내용은 (main2.java)클래스의 경로주소가 들어가 있던 외부 저장 파일 (.porperties)에서 Key= 객체이름, Value= 클래스의 경로주소로 값 뽑아내서 객체 저장소란 map에 저장했다. 해당 map에서 다시 value의 경로주소를 통해 진짜 객체를 만들어 내서 value 값들을 갱신 했다. 결국 map은 (K(객체이름), V(객체))가 되어서 사용자가 어떤 객체를 선언하려하면, new를 이용해 동적할당 하지 않고 map에서 찾아 꺼내 썼다. 그다음 main3.java에서 배운 내용은 컴포넌트 어노테이션을 이용하는 것이였다. 먼저 우리가 사용할 클래스들에는 @Component를 붙인다. 그리고 doComponentScan이라는 함수를 만든다. 해당 함수는 패키지 내의 ..

저번 시간에 최종적으로 한 것은 DI를 흉내내어 변경에 유리한 코드를 만드는 것이었다. DI는 의존성 주입으로, 어떤 객체를 소스코드 내부에서 선언하는 것이 아니라, 외부에서 객체를 생성한 후 소스코드 내부로 주입하는 것을 의미한다. 저번 포스팅에서는 DI를 흉내내기 위하여 객체 생성 기능을 하는 매소드를 이용했다. 해당 매소드에 인수로 보낸 값이 properties의 Key 값으로 있다면, 매소드는 해당 Key에 대응되는 Value (전체이름 = 경로주소.클래스이름)를 이용하여 Class class 객체를 만들고, 그 Class class 객체를 이용하여 실제 객체를 만들어 반환 했다. Properties는 map처럼 형식을 띄고 있으나, K,V에 오직 String 값만 가능했다. 이번에는 객체 컨테이..

DI란 Dependency Injection으로서 의존성 주입을 뜻한다. 이는 어떤 클래스의 객체를 new 연산자를 통해 소스코드 내부에서 만드는 것이 아니라, 해당 클래스의 객체를 외부에서 만들어서 소스코드 내부로 주입 시키는 것을 말한다. 이렇게 하는 이유는 변경에 유리한 코드를 만들어, 개발자가 할 수 있는 실수를 줄이고, test 횟수도 줄이기 위해서 이다. 그럼 변경에 유리한 코드라는 것이 무엇인지 알아보고, 이를 어떻게 표현해야하는지 알아보자. 0. 가정 class Car{} class SportsCar extends Car {} class Truck extends Car {} SportsCar car = new SportsCar (); // (바꾸려는 것) Truck car = new Tru..

alt + home 네비게이터로 가는 키 shift * 2 모두 찾는 돋보기 어디에 포커스가 있든 ESC 누르면 Editor로 돌아옴. ctrl shift A 바로 액션 뭐 있는지 찾기 ctrl tab 위에서 밑으로 // ctrl shift tab 밑에서 위로 최근에 읽거나 편집한 파일들의 목록 보기 > Ctrl + E ctrl shift E > 파일 보거나 편집한 이력이 쭉 나옴. ctr alt left right 누르면 left 전에 편집한 곳으로 감. right 뒤에서 다시 앞으로 옴 열려있는 탭들 간의 이동 alt 누르고 오른쪽 왼쪽 ctrl + / 쭉 누르면 밑으로 쭉 내려감. ctrl shift / 여러줄 주석 ctrl f 원하는 말 찾기 엔터 내려가기 shift 엔터 올라가기 ctrl + R..

요청의 파라미터가 컨트롤러 매소드의 인수로 바인딩 될 때, 파라미터는 형 변환과 데이터 검증 절차를 거친다. 형 변환은 파라미터를 바인딩될 매소드의 인수와 같은 형으로 변환하는 절차이고, 데이터 검증은 파라미터가 인수의 값으로서 말이 되는지 확인하는 절차이다. 이 둘을 모두 에러 없이 거치면 바인딩 되고, 과정에서 에러가 나면 바인딩은 실패하고 에러 내용은 BindingResult의 객체에 저장된다. 저번 시간에는 형 변환 매소드를 만들어 Binder에 등록해서 WebDataBinder가 원래 할 수 없었던 형 변환을 할 수 있도록 만드는 것을 했다. 이번엔 같은 과정을 데이터 검증 쪽에서 할 것이다. 데이터 검증의 경우에도, WDB에 기본 내장된 기능 말고 사용자가 만들어 하고 싶은 검증 절차가 따로 ..

1.WebDataBinder의 원리 (복습) (0)Binding이란? 요청의 파라미터를 컨트롤러 매소드의 인수와 연결 시키는 것을 말한다. WebDataBinder는 요청의 파라미터를 Controller Method의 인수에 맞게 형변환을 시켜주고, 또 인수로 들어갈 수 있는 값인지 확인하는 장치이다. 해당 과정을 거쳐서 파라미터가 인수와 연결된다. (1) 형 변환 요청의 파라미터는 무조건 String이기 때문에 형 변환이 필요하다. 여기서는 MyDate라는 객체가 컨트롤러의 인수로 쓰였고, 객체의 인스턴스 변수로 binding 되어야 한다. (binding 될 대상은 Spring이 알아서 잡아준다.) 따라서 "2021"을 int 2021로 바꿔주는 역할을 한다. 만약 이 과정에서 에러가 발생하면, (y..

1. DispatcherServlet이란 뭐였나? (복습) 본래 하나의 서블릿에 입력 처리 출력 과정이 다 담겨 있었다. 여기서 모든 서블릿에 공통적이고 돌아가는 원리의 차이가 없는 입력 부분을 앞으로 빼서, 하나의 서블릿으로 만들었다. (처리나 출력은 서블릿마다 기능이 다를 수 있지만, 사용자의 요청을 받는 입력부분은 거의 모든 서블릿이 공통적으로 같다.) 이것이 디스패쳐 서블릿이다. 스프링은 서블릿을 전처리 전담하는 DispatcherServlet과 처리담당 Controller, 출력담당 View로 나누어서 관심사를 분리했다. (관심사란 사용자가 관심을 가지고 해결해야할 작업을 말한다. MVC 패턴은 해결해야할 분야를 각각 DisPatcherServlet, Controller, view로 나누어서 관..

저번 시간까지 정리한 내용으로 서버 처리하다가 예외가 발생했을 시 이를 대처하는 방법이 3가지가 있었다. (1) 예외가 발생할 수 있는 구문을 try - catch로 묶는다. 이는 예외가 발생할 수 있는 구문마다 try-catch 구문으로 묶어야 해서 아주 비효율적이었다. (2) 컨트롤러 내부에 예외처리만 담당하는 매소드 만들기. 예외처리 매소드의 어노테이션은 @ExceptionHandler 이다. 작동원리는 다음과 같다. a. 해당 컨트롤러 내부의 어떤 매소드에서 예외가 발생하고, 그 매소드는 예외를 밖으로 던진다. (throws) b. @ExceptionHandler 어노테이션이 붙은 매소드 중 해당 예외를 처리할 수 있는 매소드가 있다면 catch 구문처럼 해당 예외를 객체로 받아서 처리한다. **..

컨트롤러의 매소드에서 예외가 발생 했을 시 어떻게 처리하는지에 관한 내용이다. 예외처리 안 한 경우, 서버가 어떻게 응답하는지에 대해서 알아보고 예외 처리 방법에 대해서 알아본다. 예외 처리 방법에는 try-catch 문으로 처리, @ExceptionHandler 사용, @ControllerAdvice 사용이 있다. 1. 예외처리 안 한 경우, 서버가 어떻게 응답하나? @Controller public class ExceptionController2 { // 각 매소드에서 예외 발생 시킴. @RequestMapping("/ex3") public void main() throws Exception { throw new Exception("예외가 발생했습니다."); } } 일부러 예외를 만들어 던져보았다. ..

저번 시간에 했던 내용을 복기 해보겠다. 먼저 홈화면에서 게시판 화면으로 들어가려 했는데, 이때 클라이언트로 로그인 상태인지 아닌지 체크한다. 로그인 상태라면 바로 게시판 화면으로 넘어간다. 로그인 안 한 상태면, 로그인 창을 띄운다. 클라이언트가 로그인을 하면 다시 홈 화면으로 이동한다. 로직은 밑과 같다. 우리가 이번에 하려는 것은 로그인 성공하면 다시 자기가 갈려고 했던 페이지로 다시 클라이언트를 보내는 것이다. 난 무신사에서 옷을 살려고 했는데, 로그인 상태가 아닌 것을 까먹은 적이 있다. 로그인을 하니 다시 홈 화면으로 가서 내가 살려 했던 옷을 다시 찾아야 해 짜증 났던 적이 있다. 이번 웹페이지 에서는 그런 애로사항이 없도록 게시판에 들어가려 했던 사용자가 로그인 할 시 그대로 게시판 페이지..

대다수의 웹페이지가 회원인지 아닌지에 따라 할 수 있는 행동들이 나뉜다. 우리가 만든 홈페이지에서는 클라이언트가 로그인 해야지만 게시판 페이지를 이용할 수 있다고 하자. 세션 객체 안에 id가 저장되어 있는지 아닌지를 통해 클라이언트가 로그인 했는지 안 했는지를 체크할 수 있다. 밑의 사진은 게시판에 들어가기 위한 로직을 나타낸 것이다. 1. BoardController와 boardList 만들기 우리는 지금까지 로그인 화면(loginForm.jsp)과 로그인 후 들어올 수 있는 홈 화면(index.jsp) 2가지를 만들었다. index.jsp를 살펴보면, fastcampus Home Board login Sign in This is HOME This is HOME This is HOME 위와 같이 li..

1. 세션이란? Session은 서로 관련된 HTTP 트렌젝션을 서버가 구별할 수 있도록 한데 묶어 놓는 것을 말한다. 하나의 브라우저에 대응하는 세션 객체(저장소)는 하나이다. (1대1 대응) (다른 PC에서 나온 브라우저, 한 PC에서도 서로 다른 브라우저라면 세션 ID가 서로 다르다.) (HTTP트렌젝션 - 요청과 응답 한 세트를 말함. 요청들은 서로 독립적이라, 세션이나 쿠키가 없으면 서버는 해당 요청이 같은 클라이언트에게서 온 것인지 아닌지 구별하지 못한다.) 세션은 서버에 객체로서 존재하고, 서로 연관된 요청들을 하나로 묶기 위해 쿠키를 이용한다. 2. 세션이 돌아가는 과정. (1) 세션의 생성 브라우저에서 첫 번째 요청이 오는 순간, 서버에서는 해당 요청에 대한 세션을 만든다. 그리고 요청에..

1. 쿠키가 하는 역할이 무엇일까? 특정 웹사이트에는 아이디 기억하기란 장치가 있다. 이는 한번 로그인 했으면 다음에 로그인 페이지를 재방문 했을 때, 해당 아이디가 미리 찍혀 있도록 하는 것이다. 개발자 도구를 통해 쿠키가 뭐 있나 확인해보면, id란 이름으로 쿠키가 들어있는 것을 알 수 있다. 앞에서 배웠다시피, HTTP는 상태 정보를 저장하지 않는다. 따라서 클라이언트는 연속적으로 온 두 요청이 같은 클라이언트에게서 온 것인지, 다른 클라이언트에게서 온 것인지 알 수 없다. 하지만 때때로 서버가 전 클라이언트의 행동을 기억해야만 처리할 수 있는 일이 있다. (ex - 로그인 후에만 할 수 있는 행동 등) 쿠키는 클라이언트를 식별하는 기술이다. 서버가 쿠키를 이용하면 클라이언트를 구별할 수 있다. 2..

1. 원리 (1) redirect a. 클라이언트가 특정 주소로 요청을 보냄. b. 근데 서버가 받아보니 해당 일은 해당 주소에서 처리할 수 없는 일임. c. 그래서 서버는 응답 메세지 Header에다가 상태코드 300(redirect 요청)과 함께 어디로 가야 이 일을 처리할 수 있는지 주소(location)를 같이 써서 다시 브라우저에게 보낸다. d. 브라우저가 자동으로 해당 주소로 재요청을 한다. (브라우저가 재요청 시 상단의 URL이 재요청된 주소로 바뀌어서 클라이언트도 재요청 하는 줄 알 수 있음.) e. 올바른 주소가 응답하여 클라이언트의 브라우저에 띄워진다. (이 때 이 자동요청은 오로지 GET 요청밖에 안된다. 따라서 클라이언트가 로그인 정보 쳐서 보냈다하더라도 redirect 되면 올바른..

1. @RequestingMapping more (1) RequestMethod가 다르면 같은 URL 주소를 가져도 된다. @RequestMapping만 하던 시절에는 매소드 간에 매핑 URL 주소가 같으면 에러가 났다. 하지만 @PostMapping과 @GetMapping은 서로 하는 작업이 다르기 때문에 URL 주소가 같아도 된다. @GET은 서버에서 정보를 얻어오는 거고, @Post는 정보를 서버의 데이터에 기록하는 것이다. (2)하나의 컨트롤 내 매소드 간에 동일한 주소는 @RequestMapping을 써 묶어줄 수 있다. @Contorller 밑, 클래스 이름 위에 @RequestMapping을 써서 중복되는 주소는 묶어줄 수 있다. 이러면 매소드 별로 매핑된 주소가 정말 적고, 무슨 일 하려는..

1. @ RequestMapping의 전문화 @RequestMapping으로 URL과 컨트롤러를 Mapping 해버리면 사용자는 GetMapping PostMapping 두 방법 다 사용하여 컨트롤러를 이용할 수 있다. 예를 들어 회원가입 시 GetMapping으로 스트링 쿼리에 회원 가입 내용을 다 적은 채 작성할 수도 있고, PostMapping으로 개인 정보는 전부 body에 넣어 기입 할 수 도 있다. 당연하지만, GetMapping으로 개인정보를 작성하면 브라우저에 노출되기 때문에 보안적으로 좋지 않다. 이와 같이 특정 상황에 대해 Getmapping 혹은 PostMapping으로만 컨트롤러와 브라우저가 Mapping 되게 하는 것이 가능하다. 이에 대해서 논해본다. (1) @ RequestMa..