작성
·
70
·
수정됨
0
'프록시패턴과 데코레이터패턴.pdf' p.7 하단의 설명을 이해하는데 시간이 많이 걸렸습니다.
다른 수강생분들도 참고하실 수 있도록 정리했습니다.
위 상황에서 http://localhost:8080/v2/request?itemId=hello 으로 접근하면 아래와 같은 결과가 나옵니다.
수동등록하여 컨트롤러 Bean이 생성됐다 하더라도
위 @RequestMapping
만으로 컨트롤러
로 '인식' 할 수 없음 (부트 3.0부터)
@RequestMapping
과 @ResponseBody
==> @RestController
로 교체시도
이렇게 만들면 컨트롤러
로 '인식'할 수 있다.
하지만 아래처럼 빈충돌로 애플리케이션 구동자체가 안된다.
(@RequestMapping 을 쓰던 이전에는 컴포넌트 스캔이 대상이 아니여서 자동구성 빈이 생성되지 않았고
오직 수동구성 빈만 생성됐음)
(@RestController로 변경하면서 컨트롤러로 인식하게 됐지만
자동구성으로 빈이 등록돼버리고 , 수동구성 빈 등록으로 덮어쓰기를 시도하려하지만 스프링부트는 스프링과 달리 이것을 허용하지 않고 빈충돌 에러를 발생시킴)
위 현상은 v1, v2에서만 발생한다. ('수동구성으로 진행되도록 유도된 예제'에서 불청객으로 자동구성이 발생)
반면 v3에서는 발생하지 않는다. (자동구성으로 진행됐기 때문)
따라서 자동구성 대상이 되지 않도록 v3 패키지경로를 컴포넌트스캔지정하여 v1, v2를 스캔대상에서 제외시킨다.
@RequestMapping
과 @ResponseBody
==> @RestController
로 교체
이렇게 만들면 컨트롤러
로 인식할 수 있다.
위 개선1과 달리 빈충돌없이 애플리케이션 구동이 잘 된다. (빈이 덮어써지게 3.4는 개선됐나보다)
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. 창신동 장첸님.
스프링 부트 3.0 이상의 버전에서는 @Controller
대신 @RequestMapping
을 사용한 경우, 컨트롤러로 인식하지 않는 문제가 발생할 수 있습니다. 이는 스프링 부트 3.0에서 기능의 변경 사항 중 하나로, 클래스 수준의 @RequestMapping
만으로는 컨트롤러로 인식되지 않기 때문입니다. @Controller
또는 @RestController
를 사용하여 컨트롤러를 명확히 지정해야 합니다.
@RestController
사용: @RequestMapping
을 @RestController
로 교체하면 Spring Boot에서 컨트롤러로 인식하게 되어 문제를 해결할 수 있습니다.
@RestController
는 내부에 @Controller
를 포함하고 있으며, HTTP 응답에 직접 JSON/XML 형식으로 데이터를 반환할 수 있게 해줍니다.컴포넌트 스캔 경로 조정: 불필요한 빈 충돌을 방지하기 위해 자동 구성 빈과 수동 구성 빈의 경로를 정확히 관리해야 합니다. 스프링 부트 3.0 이후 버전에서는 자동 구성과 수동 구성의 빈 충돌을 더 엄격히 처리하기 때문입니다.
최신 버전으로의 업그레이드 고려: 스프링 부트 3.4에서는 빈 충돌 문제에 대한 개선이 이루어졌을 수 있습니다. 이를 통해 spring.main.allow-bean-definition-overriding=true
설정 없이도 빈 충돌 문제를 우회할 수 있습니다.
관련하여 유사한 문제를 겪은 다른 수강생의 질문과 답변은 현재 찾기 어려워, 아래의 해당 질문을 참고하시기 바랍니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.