구체 클래스 기반 프록시 컨트롤러
134
작성한 질문수 5
강의에서는 실제 객체 Controller를 컴포넌트 스캔의 대상으로 지정하지 않았는데 자바 일정 버전 이상부터는 Controller 객체는 @Controller를 붙여야된다고 수정되어 있더라고요
근데 그러면 강의와 달리 Controller 실제 클래스를 스프링빈에 등록하고 그걸 상속받은 proxy객체도 등록했을 때,
똑같은 경로로 mapping이 오면 어떻게 되나요? 만약 문제가 생긴다면 어떻게 해결해야하나요?
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. 이응이응님.
구체 클래스 기반 프록시에서 실제 컨트롤러와 그 프록시 객체를 모두 스프링 빈으로 등록할 경우, 동일한 요청 경로(/v1/request 또는 /v1/no-log 등)에 대해 매핑 충돌이 발생할 수 있습니다. 이는 스프링이 동일한 요청 경로를 여러 빈에서 처리하려 할 때 모호성이 생기기 때문입니다.
해결 방법:
빈 이름을 다르게 설정: 컨트롤러 빈과 프록시 빈의 이름을 명시적으로 다르게 설정하여 충돌을 피할 수 있습니다.
프록시 우선 사용: 프록시 패턴의 장점 중 하나는 실제 객체를 감싸서 사용자가 프록시를 통해 간접적으로 실제 객체에 접근할 수 있도록 하는 것입니다. 따라서, 대부분의 경우 프록시 객체를 스프링 빈으로 등록하고 실제 객체 호출은 프록시를 통해 이루어지도록 설정합니다.
명시적인 설정 클래스 사용: 스프링의
@Configuration을 이용하여 프록시와 실제 객체의 빈 등록을 명시적으로 관리하고 컨트롤러 경로를 조정할 수 있습니다.
관련된 질문과 답변은 아래 링크에서 확인하실 수 있습니다:
- 인터페이스 기반 프록시 적용 후 orderController bean method 오류
- concrete proxy controller에는 requestmapping이 없지 않나요?
위 답변들이 프록시 패턴 사용 시의 빈 등록 문제 및 매핑 충돌에 대한 좋은 예시입니다. 프록시 객체가 스프링에 의해 관리되고, 적절히 경로 충돌 문제를 해결하는 방식에 대한 논의가 포함되어 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
어드바이스 순서 디폴트 기준이 궁금합니다.
0
51
1
AspectV1 예제를 @Configuration 수동 등록으로도 가능한가요?
0
78
2
구체 클래스를 상속받아 확장한 형태도 클래스패턴/데코레이터 패턴이라고 칭하나요?
0
52
1
TraceTemplate 을 미리 빈으로 등록해서 사용할때 이렇게 설정하는게 맞는건가요?
0
53
1
Decorator 에서 추상메서드로 뺄때 질문 있습니다.
0
56
1
대상 클래스에 기본 생성자가 없을 때
0
74
1
스프링 부트 버전 4.0 aop 의존성 명칭 변경
1
346
2
final 키워드 사용 관련 질문
0
75
1
안녕하세요
0
64
1
ThradLocal 실무 사례
0
97
2
실무에서의 동시성 문제
0
62
1
로그 등 부가 기능에 대한 테스트코드
0
50
1
ProceedingJoinPoint와 MethodInvocation에 대하여
0
67
1
실무 멀티스레딩에 대한 궁금증
0
69
1
안녕하세요 질문있습니다
0
43
1
AspectV3 aop 실행 순서 문의 드립니다
0
37
1
MDC vs AOP 중에 고민중입니다.
0
74
1
순환참조
0
158
2
this를 단독으로 사용할때랑 파라미터 바인딩 할때 차이
0
77
1
빈 후처리에 등록 질문 있습니다.
0
75
1
AppConfig 설정하는 설명중에 이해가 안되는게 있습니다.
0
88
1
ThreadLocal을 지역변수로 선언하면 remove가 필요할까요?
0
117
2
@Aspect 어노테이션으로 생성된 Advisor의 Bean 저장 여부
0
67
1
ThreadLocal 사용시 부작용이 있을수 있을까요? (ThreadLocal.remove()를 잘한다고 해도..)
0
73
2