게시글
질문&답변
2024.04.21
섹션6. 자동 구성 정보 파일 분리 강의에서 질문 있습니다
어려운 걸 분석해보고 계시네요. ImportSelector는 스프링에서도 독특하게 사용되는 오브젝트가 구현하는 인터페이스로 보입니다. 다른 @Configuration 클래스를 생성해내는 작업을 담당하고 있으니 꽤나 독특한 위치에 있죠. 어쨌든 @Import에 의해서 등록이 되고 이 오브젝트를 생성하는 건 스프링이니 필요한 클래스로더 등을 주입해주는 것도 스프링입니다. 이걸 일반 빈으로 등록할 필요는 굳이 없어보이네요.
- 0
- 2
- 91
질문&답변
2024.04.04
단위 테스트 구성 시 다른 오브젝트를 직접 구성해주는 과정의 용어가 궁금합니다.
테스트 스텁(test stub)이라고 합니다. 테스트 대상 객체가 동작하는데 필요한 협력 오브젝트의 기능을 간단히 구현해 놓은 것을 말합니다. 검색해보시면 관련된 좋은 설명을 많이 찾으실 수 있을 겁니다.
- 0
- 1
- 73
질문&답변
2024.04.01
dependency-management 버전 질문
재밌는 실험을 해보셨네요. 스프링을 비롯한 자바 서버 애플리케이션은 보통 수십 개에서 백 개가 넘는 의존 라이브러리들을 사용합니다. 표준 뿐만 아니라 오픈소스 기술도 많이 사용되고, 대부분 중복된 기능을 개발하기보다는 기존에 만들어져 검증된 라이브러리가 있으면 그걸 재사용하려고 하죠. 문제는 버전이 올라가면서 어떤 경우엔 호환성이 깨지고 오류가 나기도 합니다. 그래서 버전을 맞추는게 엄청나게 복잡한 부담입니다. dependency-management 플러그인은 그런 고민을 해결해줄 수 있도록 미리 검증된 버전의 라이브러리를 사용할 수 있게 도와주는 것으로 알고 있습니다. 그런데 이걸 최신 버전에 맞춰서 쓰지 않고 구버전을 써도 잘 동작한다는 말씀이네요. 그럴 수도 있습니다. 라이브러리들이 버전 올라간다고 모든게 다 깨지는 건 아니거든요. 하지만 그래도 스프링 개발팀이 많은 노력을 들여서 최신 스프링/부트 버전에 맞는 라이브러리들을 추천하고 사용하도록 권장하는 데는 여러 이유가 있습니다. 당장은 문제는 없어보이지만 어떤 새로운 기능을 쓸 때 문제가 튀어나올 수 있습니다. 동작하는 것처럼 보이지만 실은 버그가 있을 수도 있고요. 새 버전에서 성능이 개선됐는데 그게 안 된 버전을 사용하게 될 수도 있겠죠. 이걸 버전을 바꿔서 다시 프로젝트 전체를 로딩하고 어떻게 버전이 바뀌는지를 확인한 뒤에 하나씩 다 검증해보기 전에는, 최신 버전에서는 뭐가 개선됐는지 등등, 사실 잘 모릅니다. 제가 추천하기엔 이런 머리 아픈 작업은 스프링부트 개발팀이 제안해준 방식을 따라서 하시면 좋겠습니다. https://docs.spring.io/dependency-management-plugin/docs/current-SNAPSHOT/reference/html/ 이 문서도 한번 참고해보세요. 그리고 GitHub 프로젝트에 최신 업데이트가 어떤게 되고 있는지도 보시면 왜 계속 새 버전이 나오는지 이해하는데 도움이 되실 겁니다.
- 0
- 2
- 103
질문&답변
2024.03.22
web.xml -> dispatcherServlet 질문
위의 코드는 DispatcherServlet으로 보내는 패턴을 정의한 것입니다. 이건 그냥 / 로 등록해서 전체가 다 가게 하면 됩니다. *.do 와 같은 건 개별 컨트롤러에서 설정할 문제이지 저렇게 DispatcherServlet에 걸어주는 방식을 쓰지 않습니다. 부트에서 왜 ServletConfig을 넣으셨는지도 이해가 안 됩니다. 실제로 이런식으로 사용하지 않습니다. 그리고 뭐가 안 된다는 것인지도 모르겠네요. 저도 부트에서 이런식의 설정을 해서 써본적은 한번도 없습니다. 강의와 무관한 내용인데다 제가 테스트 해볼 수 있는 문제를 재현한 샘플 프로젝트를 공유해주신 것도 아니어서 더 이상 도움을 드리기는 어려울 것 같습니다. 부트의 레퍼런스에 샘플로 나오 방법이 아니라면, 아마도 부트를 쓰는한 지원하게 만드는 방법이 없을 수도 있습니다. 부트는 자신만의 방법을 고집하는 아주 일방적인 기술이라서요. 기존에 하던 방식을 가져올 거라면 부트를 쓸 이유가 없습니다.
- 1
- 1
- 134
질문&답변
2024.03.20
http api test
HTTPie 프로그램이 설치가 안 된 것 같습니다. https://httpie.io/docs/cli/windows 을 참고하셔서 설치하고 사용해보세요.
- 0
- 1
- 204
질문&답변
2024.03.14
자동구성에 이어서 질문드립니다.
A, B 모듈이 어떤 종류인지에 따라서 이야기가 좀 달라질 수는 있겠습니다. 기술 라이브러리를 제공하는 컴포넌트인가, 애플리케이션 서비스를 제공하는 것인가(service, controller, ..). 일반적인 원칙을 설명드리자면 별도의 모듈로 A, B가 존재한다면 각각의 구성 컴포넌트에 대한 @ComponentScan은 각 모듈의 최상위 빈에서 하는 것이 좋습니다. 즉, A의 빈을 B가 스캔하는 것은 일반적으로 좋은 방법은 아닙니다. 최상위 빈으로 @Configuration을 하나 넣고, 거기에 @ComponentScan도 추가한 뒤, 그 빈을 @Import하거나 @AutoConfiguration 방식으로 가져오는 것입니다. 만약 A, B가 각각 분리되어서 독립적으로 다른 프로젝트에서도 사용되고 그런게 아니라면, 단지 모듈성을 위해서 서비스 등을 분리해 놓은 것이라면 그냥 같은 패키지 루트를 공유해서, 예를 들어 A는 myproject.a , B는 myproject.b 등으로 시작하게 하고 루트 프로젝트에서 myproject 아래 것을 다 스캔하는 것이죠. 사실 이런식의 접근에는 정답도 없고 모법답안도 없습니다. 뭐가 됐든 선택하신 방식을 사용하시면 됩니다. 동작을 잘 하고, 일관성이 있다면 어떤 식으로든 상관없습니다. 여러가지 아이디어가 있다면 각 방식으로 코드를 재구성하고 코드를 읽으며 장단점을 생각해보신 뒤에 선택하셔도 좋겠습니다. 그걸 스스로 느껴보는 게 다른 사람의 의견보다 훨씬 중요합니다.
- 0
- 2
- 125
질문&답변
2024.03.12
신규강의와 스프링 3.1 책관련 질문드립니다
새로 준비중인 강의는 예제를 좀 더 최근에 사용하는 기술을 사용해서 기존 책 초반부(1-5장)에서 설명하는 스프링에 적용된, 그런데 우리가 작성하는 코드에도 반영되면 좋은 원리를 배울 수 있는 내용을 다룹니다. 이 강의로 출발해서 앞으로 개발과 관련해서는 부트 시리즈에 이어지는 내용을 참고하시면 좋습니다. 책은 좀 예전 스타일의 예제(DAO 등)이긴하지만 꽤 자세한 설명이 있습니다. 그래서 파트 1 정도라면 강의와 함께 보시는 것도 도움이 되긴할 겁니다. 양이 많기는 한데 어렵지는 않습니다. 하지만 새로운 기술 익혀 쓰기도 바쁘시다면 강의만 보셔도 됩니다. 어느 걸 딱 추천하지는 못하겠네요.
- 0
- 1
- 208
질문&답변
2024.03.12
자동구성 관련해서 질문드립니다.
자동구성은 애플리케이션 컴포넌트(repository, service, controller 등)보다는 재사용이 가능하거나 필요한 기술 컴포넌트에 보통 적용합니다. 스프링 부트의 자동 구성의 예가 그렇죠. @ComponentScan은 좋은 겁니다. 스캔을 하면 무슨 빈이 추가되는지 명확하게 보이지 않는다는 이유로 불평을 하는 사람도 있긴합니다만, 등록될 컴포넌트가 한 100개쯤 되면 @Import를 하든, @Configuration에 @Bean으로 직접 넣어서 정의를 하든, 그거 다 한 눈에 안보이기는 마찬가지입니다. 애플리케이션 빈을 추가할 때는 @ComponentScan이 최선입니다.
- 1
- 1
- 119
질문&답변
2024.02.27
안녕하세요. 토비님
안녕하세요. 기존 토비의 스프링 3.1의 핵심 내용을 스프링 6.1을 이용해서 설명하는 토비의 스프링 핵심과 원리 기초편을 지금 준비중입니다. 70% 정도 강의 녹화를 마쳤고, 빠르면 3월 말, 늦어도 4월에는 강의를 오픈할 수 있을 것 같습니다. 강의에 비해서 책이 좀 더 깊에 많은 내용을 다루긴 하지만 2010년에 나온 책이고 지금은 잘 쓰이지 않는 예전 기술과 방식을 사용한 예제로 되어있어서 보시는데 불편하실 수 있습니다. 열심히 마무리 해보겠습니다. 이어서 최신 스프링의 상세 활용법과 스프링 부트와 스프링의 세부 기술을 다루는 강의도 준비중입니다.
- 1
- 1
- 284
질문&답변
2024.02.20
섹션 9 세번째 강의 문의
JUnit의 테스트는 별도의 설정을 하지 않으면 병렬적으로 실행되지는 않는 것으로 알고 있습니다. 다만, 테스트 메소드의 실행 순서는 JUnit의 알고리즘에 의해서 결정되기 때문에 항상 작성된 순서대로 동작하지 않을 수 있습니다. 중요한 건 어떤 순서대로 테스트가 실행되더라도 결과가 동일하도록 각 테스트를 서로 영향을 주지 않은 고립된 테스트로 동작하도록 만드는 것입니다. 혹시 테스트 실행 결과가 생각한 것과 다르게 나오고, 이게 궁금하시다면 해당 코드를 GitHub에 올리고 공유해주시면 제가 실행해보고 확인해드리겠습니다.
- 0
- 1
- 102