[공유] 윈도우 사용자를 위한 http 명령어 오류 해결 방법

제가 알려드린 방법으로는 httpie 설치에 문제가 있으셨군요. 좋은 팁을 알려주셔서 감사합니다. 윈도우 환경을 준비해서 좀 더 세심하게 설치 방법 등을 연구해보겠습니다.

섹션7. 자동구성 정보파일분리 강의 질문(@MyAutoConfiguration 붙힌 이유)

@MyAutoConfiguration은 @Configuration을 메타 애노테이션으로 가지고 있으니 구성정보를 작성하는 클래스라는 것을 스프링에게 알려줄 수 있죠. 그래서 @Bean이나 @Import 등을 사용할 수 있습니다. 동시에 스프링부트의 자동 구성에서 사용하는 구성 정보를 담은 클래스라는 것을 명확하게 하기 위해서 애노테이션을 새로 만든 것입니다. 실제로는 스프링 부트는 @AutoConfiguration이라는 애노테이션을 가지고 있죠. 이걸 흉내내서 만든 것이 @MyAutoConfiguration입니다.proxyBeanMethods = false은 스프링이 최근에 추가한 방식입니다. @Configuration에서 @Bean이 붙은 메소드를 다른 여러 빈에서 중복해서 호출해서 의존관계 주입(DI)을 하고 있지 않다면 결과적으로 차이는 없습니다. 말씀하신 클래스에 이걸 붙여도 상관없습니다. 스프링이 최근에 proxyBeanMethods = false를 적극적으로 사용하고 있기 때문에 이에 대한 설명을 해봤습니다. 스프링 부트를 이용해서 개발하면서 가질 수 있는 질문과 동작 원리를 모르기 때문에 오해할 수 있는 지점, 그리고 사용하는 기술의 동작 방식에 대한 이해를 돕고자 만든 강의입니다. 단순하게 내용을 외우는 것은 별 도움이 안 될 것입니다. 일단 자동 구성이 어떻게 동작하는지, 지금 적굥된 자동 구성이 어떤 일을 하고 있는지 등이 궁금할 때, 다시 강의 내용을 확인해보시고, 알려드린 방법으로 스프링 부트의 기술을 살펴보시는 경험이 필요합니다. 그래도 제가 중요하다고 강조드린 내용은 기억해두시면 좋겠습니다. 더 궁금하신 내용이 있으면 다시 알려주세요.

WebApplicationContext를 DispatcherServlet에 this로 넘기는 것

어느 수업의 어느 시점에 나오는 예제인지를 알려주시면 좀 더 정확하게 답을 드릴 수 있을 것 같습니다. ApplicationContext 인터페이스로 대표되는 스프링 컨테이너는 사실 굉장히 복잡하고 깊은 여러 인터페이스와 클래스 상속 구조를 가지고 있습니다. 어떤 방식으로 스프링의 구성 정보를 전달하는가에 따라서 실제 사용되는 클래스가 달라지죠. 그런데 예제와 같이 스프링의 기능을 살펴볼 때는 필요한 기능을 가진 가장 최상위 인터페이스 또는 클래스를 사용해서 코드를 만듭니다. 일반적인 스프링 개발에선 사실 이 ApplicationContext를 구현한 스프링 컨테이너를 직접 액세스할 경우는 거의 없습니다. 다만 강의에서는 동작원리를 살펴보기 위해서 적절한 타입으로 만들어진 스프링 컨테이너를 받아서 사용하고 있죠.ApplicationContext로 대표되는 스프링 컨테이너 오브젝트가 웹과 관련된 컨텍스트에서 사용될 때는 꼭 Web이 들어간 ApplicationContext를 사용해야 합니다. DispatcherServlet 등에서 사용하는 메소드를 가지고 있어야 하거든요. 그래서 GenericWebApplicationContext 타입을 썼을텐데, 결국 이것도 상위는 GenericApplicationContext 혹은 가장 최상위 ApplicationContext를 구현한 것이기 때문에, 만약 코드에서 사용하는 기능이 getBean()과 같이 가장 단순한 거라면 ApplicationContext로, registerBean() 처럼 코드로 빈을 등록하는 작업이 필요한 경우라면 이 메소드를 가진 상위 타입인 GenericApplicationContext로 받아서 사용할 뿐입니다.일단 강의에서는 스프링 컨테이너가 이런 작업을 하고 있구나 정도만 이해하시면 충분합니다. 그때마다 쓰이는 클래스나 인터페이스 타입이 다르긴 하지만 결국 이게 우리가 개발할 때 만들어지는 스프링 컨테이너가 구현하거나 상속한 인터페이스나 클래스 중의 하나일 것이라고 생각하시면 충분할 것 같습니다.내부 구조가 더 궁금하시다면 스프링 소스 코드에서 ApplicationContext 인터페이스로부터 출발해서 이를 확장한 여러 인터페이스, 그리고 이를 구현한 각종 클래스를 살펴보시면 됩니다. 흥미롭긴하지만 사실 스프링을 더 깊이 이해하는데 크게 도움이 될 것은 아니라서, 그 부분을 자세히 보여드리면서 설명드리진 못했네요. 말씀하신 것처럼 예제 코드에서 필요로 하는 메소드를 가지고 있는 타입이라면, 그 타입으로 받아서 사용해보세요. 좀 특별한 케이스를 제외하면 잘 변환이 될 겁니다. 코드를 변경하고 컴파일과 동작이 잘 되면 아무 문제가 없는 것입니다. 혹시 더 궁금하신 게 있으시면 보고 계신 코드를 포함해서 다시 질문을 해주세요. 감사합니다.

생성자 파라미터성자 파라미터

스프링은 컴포넌트스캔이든 명시적인 빈 팩토리 메소드 선언이든 상관없이 등록 가능한 모든 빈 정보를 먼저 수집하고 이 사이의 의존관계를 확인합니다. 그래서 그에 따라 각 빈의 생성 순서를 조정합니다.위와 같은 @Bean 팩토리 메소드를 이용하는 경우 아래 transactionManager()를 실행해서 빈을 만들려면 DataSource 타입의 빈이 필요하다는 것을 알 수 있고, 위 dataSource()를 이용해서 빈을 먼저 만든 뒤에 그 오브젝트를 아래 transactionManager()의 파라미터로 넘겨줍니다. 순환참조가 발생하지 않는다면 이와 같이 다른 빈을 파라미터로 주입 받아서 새로운 빈을 생성하는 방식을, 생성자 주입 또는 @Bean 메소드 파라미터 주입 등에 활용할 수 있습니다.

인프라 빈 구성 정보의 분리에서 EnableMyAutoConfiguration 질문드립니다.

@Configuration은 @Component를 메타 애노테이션으로 가지고 있어서 애노테이션이 붙은 클래스를 빈으로 등록되게 합니다. 그런데 @Configuration이 꼭 클래스에 바로 지정된 애노테이션, 여기서라면 MySpringApplication에 있어야하는 것은 아닙니다. 메타 애노테이션으로 따라가다 @Configuration이 나와도 적용이 되겠죠. 이후에 언제라도 @Bean을 넣어서 수동 빈 등록이 가능하도록 만들기도 하고, 해당 클래스가 전체 애플리케이션 컨텍스트가 등록되는 기반이 되는 클래스임을 나타내도록 하기 위해서라도 @Configuration이 바로 붙어있는게 좋은 것 같습니다. 스프링 부트의 @SpringBootApplication는 @SpringBootConfiguration 애노테이션을 가지고 있고, 이 안에 메타 애노테이션으로 @Configuration이 있습니다. 그래서 @SpringBootApplication이 붙은 클래스가 @Configuration 기능을 수행하는 것이죠.지금 예제에서는 @EnableMyAutoConfiguration 위에 @Configuration이 있어서 이게 적용이 되는 것으로 보이는데, 그래도 @MySpringBooApplication이 기본 @Configuration 클래스임을 쉽게 볼 수 있도록 그 위에 @Configuration이 있는 것이 적절해보입니다. Autoconfiguration은 구현 방법에 따라서 @Configuration이 붙은 config 클래스를 직접 참조하지 않을 수도 있거든요.

질문드립니다.

스프링 부트 3.x에서도 강의 예제는 몇 가지 변경사항만 따르면 문제 없이 동작할 것으로 기대합니다. 부트 3가 되면서 달라지는 점은 마지막 수업 영상에서 설명드렸고, 공식 예제에서 3.0으로 모든 예제를 다시 재개발한 것을 브랜치로 분리해두었습니다. build.gradle은 애초에 Spring Initializer가 만들어준 것을 그대로 사용했기 때문에 다르게 변경할 필요는 없을 것입니다. 혹시라도 3.x의 몇 가지 달라진 점을 알려드린 것 외에 다른 문제가 발생하면 알려주세요.

spring boot 3.3.7로 학습중입니다.

스프링 버전이 올라가면서 DispatcherServlet의 동작 방식이 변경되었습니다. 스프링에선 보통 구버전의 코드와 호환성을 잘 지켜주는 편인데, 이건 예외적으로 @RestController 사용이 강제되었습니다. 관련해서는 마지막 수업으로 추가한 스프링 부트 3으로 학습하실 때 주의할 점을 참고해주세요. 또, 유사하 질문이 여러번 올라왔으니 관련된 기존 답변도 찾아보실 수 있을 겁니다.

spring start io 에서 이제더이상 2.x버전은 지원하지 않는 것 같습니다.

강의나 출시된 이후에 스프링 부트 3이 나왔고 계속 업데이트 중이네요.대부분의 내용은 스프링 부트 3에서도 문제 없이 예제를 통해서 학습하실 수 있습니다. 강의 마지막 수업에 3에서 할 때 몇 가지 주의할 점에 대해서 정리해두었습니다. 그리고 GitHub의 예제를 받으시면 3.0으로 예제를 구성한 브랜치를 찾으실 수 있습니다. https://www.inflearn.com/courses/lecture?courseId=329974&unitId=144737스프링 이니셜라이저(start.spring.io)를 이용해서 강의에 나온 버전을 바로 받아서 할 수 없지만 동일 버전(2.7.6)으로 예제를 해보고 싶으시면 방법이 있습니다. 공식 예제를 GitHub에서 받으시고 IntelliJ의 Git commit 목록에서 가장 최초 커밋을 선택한 후에 checkout을 하면 2.7.6으로 처음 Hello Controller까지만 추가된 예제 상태로 전환할 수 있습니다. 여기서부터 이후 강의 내용을 따라하시면 강의와 동일한 버전과 상태로 코드를 만들어보실 수 있습니다.

Springboot 3.2 이상에서 파라미터 추론관련

좋은 정보 제공해주셔서 감사합니다.자바 컴파일러의 메소드 파라미터 메타정보를 컴파일 시점에 남기려면 -parameters 정보를 줘야하죠. 이를 통해서 파라미터 이름을 가져오는 방식을 스프링 6부터는 디폴트로 만들었기 때문에 이 컴파일 옵션이 없으면 @RequestParam 등에 명시하지 않은 경우 바인딩할 query string 이름을 피라미터 이름으로부터 가져올 수 없는 문제가 발생합니다.스프링 부트 강의에서는 그 이전에 많이 알려져있던, IntelliJ에서 프로젝트 빌드와 테스트 등의 성능을 좀 더 높일 수 있도록 iIIntelliJ의 Gradle build 설정의 디폴트인 Gradle 대신 IntelliJ IDEA로 변경하는 팁을 말씀드렸습니다. 최신 장비가 아닌 경우 조금의 실행 성능 개선 효과가 있었습니다. 하지만 스프링이 기본으로 제공하는 Gradle을 이용한 빌드와 미묘한 차이가 있기 때문에 최근에는 가능한 Gradle을 이용한 빌드를 사용하는 것이 권장됩니다. CI 과정에서 빌드할 때나, 배포 후에 Spring Boot task를 이용해서 실행하는 것과 동일한 설정을 개발 장비에서도 적용하는 것이 바람직하기 때문이죠. 그 중의 하나가 Gradle 대신 IntelliJ로 빌드하는 옵션을 선택하는 경우 -parameters가 추가되지 않습니다. 그래서 예제와 같은 경우에는 에러가 발생하는 것입니다. 반면 스프링 부트 프로젝트에서 사용하는 Gradle 빌드 기본 설정을 사용하면 자바 클래스를 컴파일할 때 -parameters 옵션을 기본으로 추가해줍니다. 그래서 스프링만을 이용하고 독자적인 빌드 코드를 만들어서 만들지 않고, 스프링 부트를 기본 Gradle을 이용해서 개발하고 빌드하는 경우엔 사실 @RequestParam 없이도 메소드 이름을 잘 가져옵니다.저도 IntelliJ에서 스프링 부트 프로젝트를 만들고 디폴트 빌드 옵션(Gradle)을 그대로 사용해서 예제를 만들었기 때문에 최근까지도 별 문제가 없었던 듯합니다.

binding error

일반적으로 properties가 아니고 yml이라고 prefix 관련 문제가 발생하지는 않을텐데요. 정확히 어떤 상황인지 올려주신 코드만으로는 파악하기가 어렵습니다. 실제 에러가 발생하는 코드 전체를 GitHub에 공유해주시면 받아서 한번 확인해보겠습니다. 코드와 함께 어떻게 실행을 할 때 에러가 발생하는지도 알려주세요.