안녕하세요 강사님! 덕분에 수업 잘 듣고있습니다. 스프링 통합 테스트 강의에서, 테스트 코드의 join함수를 실행시켰더니 java.lang.IllegalStateException: java.sql.SQLException: Connection is closed 에러가 발생했습니다. 원인파악을 위해 join함수 처음부터 천천히 디버깅을 시도했는데, JdbcMemberRepository 클래스의 save함수에서 try 구문의 conn을 할당받는 첫번째 pstmt변수에서 IllegalStateException을 발생시켰습니다. 어떤 원인으로 에러가 발생했으며, 해결방법이 궁금합니다.  아래에 제가 작성한 오류와 연관된 코드들과 에러메시지 첨부합니다.   *close함수에서 conn.close()를 close(conn)으로 수정했더니 해결됐습니다. [테스트코드] [JdbcMemberRepository 클래스] [MemberService 클래스] [에러메시지]

안녕하세요! 강의를 다시 보다보니 제대로 이해한건지 확실히 하고 넘어가고 싶어서 글을 쓰게 되었습니다.   Repository에서 interface로 선언한 것은 각 기능별로 저장할 때 어떤 타입? 으로 저장할지(list 등) 이며 이를 가지고 class에서 implements를 하여 실제 구현체를 만드는데 각 기능별로 저장한 값을 어떻게 반환할지 단순히 데이터의 저장을 위한 기능   Service에서는 앞서 Repository와 Domain에서 정한 것을 가지고 실제로 동작하는 기능(조건이 있다면 조건 로직, 검증을 해야한다면 검증 로직 포함)을 작성하는 것으로 이해했습니다.   실제 구현 할 때 Service 부분을이 아무래도 비즈니스 로직이다보니 해당 부분에서 오류가 발생한다면 전반적인 작동에도 문제가 생기겠죠?

 .

안녕하세요 영한님. 강의 늘 잘 듣고 있습니다.이번 강의를 듣던 중 Setter Injection 사용 지양에 대한 이유를 제가 제대로 이해하지 못해 질문 올립니다.Repository의 경우 런타임에 한 번 주입시켜놓으면 수정할 일이 없는데 굳이  그것을 Setter 메소드로 열어놓아 유지보수시 추적을 힘들게 할 필요 없다...이런 느낌으로 이해했는데 맞는지 알고 싶습니다.

안녕하세요. 강의를 듣다 궁금하게 있어서 질문드립니다. 강의 중 for문을 돌려서 강제로 프록시를 초기화하는 부분이 있는데요. 제가 프록시 강의를 듣기로는 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때는 프록시를 초기화하면 문제가 발생하는 것으로 알고 있습니다. 그리고 트랜잭션이 걸려있는 서비스단에 트랜잭션이 끝나면 영속성 컨텍스트가 끝나는 것으로 알고 있는데요. 현재 코드는 서비스가 아닌 Repository에서 바로 값을 가져오고 있고 해당 클래스는 트랜잭션이 걸려있지 않기 때문에 아직 영속성 컨텍스트가 끝나지 않아 컨트롤러에서 프록시 초기화가 가능한 것인가요?

[SpringConfig]   [TimeTraceAop]   [ERROR]   어떤문제인지 잘모르겠습니다

안녕하세요, 몇 가지 궁금한게 있어서 질문드립니다.   1. (2:10 )서비스 계층에서 로그인 체크 비즈니스 로직을 사용한 이유가 있을까요?? 2.  (8:10) 글로벌 오류로 처리하고 다시 폼으로 돌려보냈는데, 그렇다면 예외 처리는 어떤 경우에 써야하는 것인가요??   항상 답변 감사합니다!!

안녕하세요 영한님 강의 후반부에 커맨드와 쿼리 분리 라고 말씀하셨는데   여기서 뜻하는 커맨드는 어떤 것을 의미하는 것일까요?

질문용 파일 링크: https://drive.google.com/file/d/1H7Jk68AinSPuCjEWiavLgFMpQtEuHdhT/view?usp=sharing   gradle build를 실행할 때 계속 오류가 납니다. 우측의 Gradle Tab > (프로젝트명) > Tasks > build > build 실행jar 파일만 생성시킬 땐 무사히 만들어지는데 build 명령을 내릴 때는 test code 단계에서 계속 오류가 납니다. test code가 분명 있는데도 찾지를 못하네요. ClassNotFoundException   자주 하는 질문에 적어주신 방법은 다 시도해봤습니다. 1. IntelliJ IDEA로 test code 실행주체 바꾸기, 2. 설정이 java 11로 제대로 되어있는지 확인하고 바꾸기(자주 하는 질문 매뉴얼(https://docs.google.com/document/d/1j0jcJ9EoXMGzwAA2H0b9TOvRtpwlxI5Dtn3sRtuXQas/edit#heading=h.f9xqb7l8nuph)에 적으신 대로 선택했습니다). 3. project close 한 다음에 build.gradle 파일을 open as project로 열어서 재실행하기 4. 혹시나 버전 호환성 문제일까 싶어서 원래는 2.6.4 버전이었는데 강의에서 나온 2.3.1 버전으로 다운그레이드해서 재실험해봤거든요. 그런데도 똑같은 오류가 계속 뜨네요.   위의 파일 링크 안에도 포함되어있긴 하지만, 더 빨리 찾으시라고 아래에 error log 따로 적어봅니다.   org.gradle.api.internal.tasks.testing.TestSuiteExecutionException: Could not execute test class 'KYH.Elementary.ElementaryApplicationTests'. at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:53) at java.base@11.0.14/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base@11.0.14/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base@11.0.14/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base@11.0.14/java.lang.reflect.Method.invoke(Method.java:566) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33) at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94) at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) at org.gradle.api.internal.tasks.testing.worker.TestWorker$2.run(TestWorker.java:176) at org.gradle.api.internal.tasks.testing.worker.TestWorker.executeAndMaintainThreadName(TestWorker.java:129) at org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:100) at org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:60) at org.gradle.process.internal.worker.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:56) at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:133) at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:71) at app//worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:69) at app//worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:74) Caused by: org.gradle.internal.UncheckedException: java.lang.ClassNotFoundException: KYH.Elementary.ElementaryApplicationTests at org.gradle.internal.UncheckedException.throwAsUncheckedException(UncheckedException.java:68) at org.gradle.internal.UncheckedException.throwAsUncheckedException(UncheckedException.java:41) at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.loadClass(JUnitPlatformTestClassProcessor.java:112) at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.access$100(JUnitPlatformTestClassProcessor.java:54) at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.execute(JUnitPlatformTestClassProcessor.java:89) at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.execute(JUnitPlatformTestClassProcessor.java:79) at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) ... 18 more Caused by: java.lang.ClassNotFoundException: KYH.Elementary.ElementaryApplicationTests at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:398) at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.loadClass(JUnitPlatformTestClassProcessor.java:110)

스프링1 강의에서   핸들러 매핑시 스프링은 어노테이션기반의 컨트롤러를 RequestMappingHandlerMapping 타입으로 등록한다고 배운것 같습니다.   인터셉터의 preHandle이 어뎁터를 실행시키기 전에 실행된다면, 매개변수인 Object handler가 RequestMappingHandler관련타입으로 등록되어있을것이라 생각했는데...   HandlerMethod타입으로 등록되어있다 하셔서 제가 무엇을 놓친것인지 궁금합니다.    RequestMappingHandlerAdapter에도 handle 메서드에 HandlerMethod를 파라미터로 받고있는것으로 보면.. 스프링이 어노테이션 기반 컨트롤러를RequestMappingHandlerMapping에 등록할때부터 HandlerMethod타입으로 변환해서 올려준다고 생각하면 맞을까요?

안녕하세요 영한님!! 강의 중 궁금한 사항이 있어서 질문하게 됐습니다 위 코드를 실행 했을때 영한님과 동일하게 map과 list에 값이 안들어가 있었습니다. 그런데 여기서 의문점이 생겼습니다. AnnotationConfigApplicationContext을 통해서 스프링 컨테이너에 DiscountService가 등록되고 @Autowired를 통해서 매개변수에 있는 DiscountPolicy 빈을 찾아서 의존관계를 주입 하는걸로 알고 있습니다. 그런데 AnnotationConfigApplicationContext에 AutoAppConfig를 아직 명시 안했기 때문에 @Component가 붙은 Fix,Rate가 아직 빈으로 등록이 안돼서,  "현재 컨테이너에는 해당 빈이 없으니 오류 메시지를 띄워야 하는게 아닌가?"  라는 생각이 들었습니다. 위 질문에서 제가 잘못 이해한점이 있는지 만약 제가 이해한게 맞다면 왜 오류 메시지를 안띄우는건지 궁금합니다!  

안녕하세요   1. 요청에 매핑할 때 @GetMapping(/text-basic) 으로 하든 @GetMapping(text-basic) 으로 하든 전혀 상관이 없는 것인가요? 2. 뷰를 리턴할 때 return /basic/text-basic으로 하든 return basic/text-basic으로 하든 상관이 없나요?? 실수로 /를 빼고 실행을 했는데도 제대로 실행이 되길래 맨 앞에 /를 빼거나 넣어봤는데 코드가 문제없이 실행이 되길래 질문드립니다.   항상 답변 감사드립니다.

안녕하세요. 다름이 아니라 EventValidator 에서 implement Validator 를 쓰는것과 안쓰는것 차이를 잘 모르겠습니다.   감합니다.

안녕하세요:)    영한님의 강의을 듣다가 궁금한 점이 생겨 질문 남기게 되었습니다.    영한님의 이번 강의에서 설계 단계가 다음과 같이 진행됐습니다. 1. 요구사항을 분석하기. 요구사항을 분석해, 도메인을 나누고 도메인간의 관계를 설정함 그리고 도메인 설계도를 작성. 2. 도메인 설계도를 기반으로 엔티티 설계도 만들기 3. 테이블 설계도 만들기.   여기서 궁금한 점이 생겼습니다. 도메인 설계도를 이용해 테이블 설계도를 먼저 만들고, 엔티티 설계도를 만들어도 되는건가요?   제가 생각하기에는 도메인 설계도를 이용해 테이블 설계도를 만들고, 그 후 테이블에 매핑되는 엔티티들을 만든 뒤 연관관계가 필요하면 연관관계를 만들어주는 식으로 테이블 설계도와 엔티티 설계도를 매핑을 하는게 더 자연스럽다고 생각했습니다.    혹시 엔티티 설계도를 먼저 만든 이유가 있을까요?  ---------------------------------------------------------- 제가 생각해본 이유로는 아무래도 엔티티 설계를 먼저하는게 더 객체지향적인 설계가 가능하기 때문인 것 같은데, 혹시 제가 생각한 이유가 맞는건가요? 

안녕하세요 김영한 개발자님! 강의 항상 잘 듣고 있습니다. @RequestParam과 @ModelAttribute 파트를 듣고 살짝 헷갈리는게 있어서 질문글 남겨요 @RequestParam은 만약 url을 localhost:8080/?username=inflearn&age=20 이라고 보냈을 때 @RequestParam String username, @RequsetParam int age 에 각각 inflearn, 20이 바인딩 되는 것이라고 이해했습니다. @ModelAttribute는 객체에 setter, getter 역할을 대신해주는 것이라고 이해했습니다.  제가 제대로 이해한게 맞을까요? 제대로 이해한게 맞다면 저 두개의 차이점이 무엇인지 잘 모르겠습니다ㅜ 단순히 RequestParam은 int, string 같은 일반타입이고 ModelAttribute는 객체를 대상으로 하는건가요? 아니면 RequestParam을 더 편리하게 만든게 modelAttribute라고 이해하면 되는걸까요? 감사합니다.          

[질문 내용]안녕하세요. 강의 잘 듣고있습니다~~   다름아니라 리플랙션 강의 내용중 람다를 사용해서 공통화하는것도 가능하다 하셨는데요, 람다의 어떤 특징때문에 이루어 지는지 궁금합니다.   나름대로 생각해봤는데 함수형프로그래밍 (매개변수에 함수로직을 넣을수있는)개념을 써서 공통화 시키는게 맞는지 궁금합니다.   또는 리플랙션 처럼 람다 역시 런타임에 동적으로 클래스를 정의되고 그 인스턴스를 생성해서 반환하는 특성을 의미하신건가요?   질문이 어려우실수도 있는데 실마리라도 주시면 감사하겠습니다. ^^ ================= 답을 찾은것 같습니다. 혹시 저와 같은 궁금증을 가진분을 위해 남겨놓겠습니다.

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) This application has no explicit mapping for /error, so you are seeing this as a fallback. There was an unexpected error (type=Not Found, status=404).   여러분 혹시 이런 오류가 나타난다면 @ServletComponentScan이 등록되어 있는 메인 클래스의 패키지 명이나 위치를 확인해보세요. 메인 클래스 경로가 최상위 위치어야만 내부 탐색이 정상 작동합니다.   특히 스프링 부트 스타터에서 프로젝트 생성 시 오타가 발생한 경우엔 간단한 실수인줄 모르고 저처럼 불필요한 삽질을 하게 됩니다. ㅠㅠ   질문) 패키지명 오타로 인한 서블릿 컴포넌트 스캔 오류 발생 -> 404 에러가 있었는데요. URL 파라미터와 RequestParamServlet 내부 객체가 일치하는 것과 서블릿 컴포넌트 스캔이 어떻게 연관되어 있길래 요청 리소스가 없다고 판단하게 된건지(404) 궁금합니다:) 요청 승인을 거부한 것이라면, 왜 자동으로 처리된건지도 궁금합니다:) 혹시 질문이 이상하다면 죄송합니다.    

[질문 내용]안녕하세요. 저는 코틀린으로 코드를 짜며 수업을 듣고 있습니다.   kotlin에서는 빌드 순서때문에 lombok을 적용하기 까다롭다고 알고 있는데, 실무에서 코틀린 프로젝트를 하실 때 lombok적용여부와 만약 lombok을 사용하신다면 적용방법이 궁금합니다!   항상 좋은 강의 감사합니다.

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오) 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예[질문 내용]여기에 질문 내용을 남겨주세요. 항상 좋은 강의 감사합니다. 강의를 한번 보고 복습하던 도중 request scope 빈의 생성 시점이 헷갈려서 질문남깁니다. reqeust scope의 경우 http 요청이 들어오고 나갈때까지 유지되는 빈이라서 당연히 예제에서 http 요청이 들어오는 시점에 생성이 된다고 생각했습니다. 그리고 ObjectProvider의 getObject() 메서드 를 이용하면 request scope이 생성시점을 지연한다고 확인했는데 정확히는 http 요청시 생성된 빈을 DL 함으로 스프링 컨테이너에게 request scope 빈을 요청하는 시기를 지연한다고 생각하면 되는건가요? 앞서 배웠던 prototype의 경우는 클라이언트가 요청하면 생성되는거라 getObject() 시점에 생성되는거구요.

검색을 해보아도 동일한 에러와 관련된 글이 거의 없습니다. 별다른 코드도 없는데 무엇이 문제일까요? 그리고 보니까 pc 내의 모든 프로젝트에서 똑같은 에러가 발생하네요. 무슨 설정을 해야 해결되는지 모르겠습니다. 아래의 에러는 IntelliJ 오른쪽 사이드 바에 있는 build 를 클릭했을 때 나는 에러입니다. build.gradle에 에러가 있는건지 뭔지 모르겠네요.참고로 settings : gradle -> IntelliJ 로 변경했습니다.