강의 마지막에 언급하는 '다음 강의'란?

자체 해결: 섹션 10 - 완강을 축하드립니다 를 보니까 다음 강의 = 근본깃-완성이 맞네요!

8강 git status 관련 질문

git-scm의 설명 중 일부를 첨부합니다.git-status - Show the working tree statusDisplays paths that have differences between the index file and the current HEAD commit...결론만 말씀드리자면, 다음 상황 중 하나에 속한 파일들만이 git status 명령에 의해 출력됩니다.UntrackedUntracked files: 부분에 출력마지막 커밋 시점 이후로 변경 사항이 있는 Tracked 파일변경 사항이 git add로 staged 된 경우에는 Changes to be committed: 부분에 출력변경 사항이 아직 staged가 아닌 경우에는 Changes not staged for commit: 부분에 출력즉, 이전 강의에서 vi rectangle과 vi circle 파일을 생성하고 커밋하셨으므로 두 파일은 마지막 커밋 시점 이후로 변경 사항이 존재하지 않습니다. 따라서 git status 명령에 의해 출력되는 대상이 아닙니다.두 파일은 여전히 working directory에 존재하며, git의 추적 대상입니다.(사진)

트랙잭션 종료 후에 setAuotoCommit(true)로 변경하는 이유가 무엇인가요?

David님 답변에 추가적으로'처음 세션을 얻을 때는 보통 기본값(autocommit=true)임을 기대'하기 때문에 이후에 본인이 아닌 다른 사용자가 세션을 얻을 때 이 기대에 부응할 수 있도록 바꿔주는 이유도 있을거라 생각합니다.커넥션 풀을 생성하기 전에는 항상 새로운 커넥션이 생성되었기 때문에, autocommit=true로 설정된 커넥션을 받게 되지만 커넥션 풀을 통해 받으면 누군가 사용했던 커넥션을 받게 되는 셈이니 (이전 사용자가 커넥션에 대한 옵션을 바꿔놨을 것에 대비하여) 초기화된 상태로 만들어주는 것이죠.

레포지토리가 트랙잭션 동기화매니저에서 커넥션을 가져오는 부분에 대한 질문이 있습니다.

DataSourceUtils에서 TransactionSynchronizationManager를 import하고 있습니다.그리고 TransactionSynchronizationManager의 모든 메서드와 필드는 static입니다. 따라서 DataSourceUtils의 메서드들은 TransactionSynchronizationManager.xxx()로 static 메서드를 호출하여 동기화 매니저를 이용합니다.ThreadLocal을 사용하기 때문에 컨텍스트가 특정 인스턴스에 종속되는 것이 아니고, (아마도) threadId로 구분하기 때문에 모두 static으로 관리하는 것 아닐까싶네요.결론적으로, 트랜잭션 매니저와 데이터소스 유틸 모두 동기화 매니저의 static 영역에 접근해서 커넥션을 얻습니다. 이때 스레드별로 저장 공간이 분리되는데, 웹 애플리케이션에서 사용자별로 스레드가 할당되기 때문에 동일한 스레드의 요청이라면 ThreadLocal의 로직에 의해 같은 저장 공간에 접근하게 됩니다.

400번대 에러 응답이 모두 404.html로 됩니다.

우리가 /error-400으로 요청한다고 해서 서버에서 400 에러가 발생하는 것은 아닙니다. 지금은 ServletExceptionController의 /error-404 경로에 매핑된 컨트롤러 메서드 내부에서 sendError(404)를 호출하므로 경로와 발생 에러가 일치하는 것입니다.따라서 작성자님의 의도대로 하려면 ServletExceptionController 코드에 아래 코드를 추가해주시고, /error-400으로 요청하시면 4xx.html이 렌더됩니다.@GetMapping("/error-400") public void error400(HttpServletResponse response) throws IOException { response.sendError(400, "400 오류!"); }질문자님의 현재 상태에서의 /error-400 요청은 존재하지 않는 페이지에 대한 요청이고, 이 경우에는 기본적으로 404 에러가 발생합니다.요청 경로에 400이라고 적는다고 해서 마법처럼 400 에러가 발생하지 않는다는 것이죠.

preHandle에서 핸들러를 파라미터로 받을 수 있는 이유

ai 설명처럼 디스패처 서블릿에서 요청에 응답하기 위해 필요한 객체들(핸들러 어댑터, 핸들러)을 정해주기 때문에 그 이후에 실행되는 인터셉터에서는 파라미터로 받을 수 있습니다.

숫자입력 시 int 형 범위가 넘어가는 경우

기본적으로 HTML Form 입력은 String으로 전송이 됩니다.즉, int 범위 내인 10000을 입력하더라도 일단 String으로 전송이 되고, 서버에서 이를 int로 바인딩하는 것입니다. 이때는 바인딩에 성공하겠죠.따라서 1111111111(11개)도 일단 String으로 전송이 되고, 서버에서 이를 int로 바인딩 시도하지만 실패하기 때문에 서버는 "숫자가 아니다" 라고 판단합니다. 이때 질문자님의 의문은 "int 범위는 아니어도 long 범위 내라서 숫자를 입력한 것은 맞지 않나?" 인데요. 여기서 앞서 말씀드린 것처럼서버는 (HTML Form 입력의 경우) 10000이나, 111111...이나, "abc"나, ... -> 결국 문자열로 받는다.받은 문자열을 int 타입으로 변환 성공하면 "숫자가 입력된 것이구나" 라고 판단할 뿐입니다.서버 측에서 애초에 int 타입으로 설정했으므로, '숫자'의 정의가 '십진수들의 조합(크기 상관 x)'가 아니라 'int형 범위 내의 십진수들의 조합'인 것이지요. 따라서 질문자님 의도대로 동작하게끔 하기 위해서는 서버 측에서의 '숫자'에 대한 정의를 int에서 long으로 변환해주면 됩니다.즉, hello.itemservice.domain.item 경로의 Item 파일의 코드를 다음과 같이 변경하면 됩니다.(추가로 생성자나 price에 대한 계산 결과를 변수로 받는 부분도 모두 long으로 변경해줘야 됩니다.)package hello.itemservice.domain.item; import lombok.Data; @Data public class Item { private Long id; private String itemName; private Long price; private Integer quantity; public Item() { } public Item(String itemName, Long price, Integer quantity) { this.itemName = itemName; this.price = price; this.quantity = quantity; } } 결과 사진(사진)

수업 코드 제공 관련 문의

섹션1. 강의 소스 코드 확인하시면 됩니다.

RequestMappingHandlerAdapter의 Controller 호출 과정

질문을 남기면서 생각을 정리하고, 해당 부분 영상을 다시 돌려보니 영한님께서도 방식2가 아니라 방식1로 설명을 하셨다는 판단이 드네요!처음에 리졸버 -> 컨트롤러로 가는 점선 화살표로 인해 헷갈렸습니다.

RequestMappingHandlerAdapter의 Controller 호출 과정

글을 다 작성하고 나니 새로운 흐름(방식3)도 생각이 드는데요. 방식3(이 강의 이전 그림 기반의 흐름) 핸들러 어댑터 -> 컨트롤러 호출(현재 흐름) 핸들러 어댑터 -> 리졸버 -> 컨트롤러 . 이렇게 중간에 리졸버를 껴서 호출 방식1, 2, 3 중에 어떤 것이 적절한 흐름인지 궁금하네요 ㅠ