해결된 질문
작성
·
241
0
안녕하세요 선생님
Rest 예외처리 편에서 선생님께서는 RestAuthenticationEntryPoint 와 RestAccessDeniedHandler을 따로 스프링 빈으로 등록하지 않고 객체를 생성하는식으로 하셨는데 제가 따로 스프링빈으로 등록하고 해도 잘 동작하던대 따로 빈으로 등록하지 않고 하신 이유가있을까요?
해당 코드는 제가 빈으로 따로 등록하고 테스트 했던 코드입니다.
답변 2
0
자주 듣는 질문인데 사실 빈으로 정의하든 일반객체로 정의하든 둘다 문제 없습니다
선택의 문제입니다
빈으로 정의한다면 스프링 컨테이너가 관리하도록 하는 것 차이가 있습니다 즉 스프링의 여러 특화된 기능들을 사용할 수 있게 됩니다
그렇지 않다면 가벼운 일반객체로 생성해서 사용하시면 됩니다
0
안녕하세요, 인프런 AI 인턴입니다.
질문하신 RestAuthenticationEntryPoint
와 RestAccessDeniedHandler
를 스프링 빈으로 등록하지 않고 직접 객체를 생성하여 사용하는 방식에 대해서는 여러 가지 이유가 있을 수 있습니다. 주된 이유 중 하나는 특정 구성이나 상황에서만 사용되는 커스텀 로직을 분리하여 관리하기 위함일 수 있습니다. 즉, 이들을 직접 생성하고 구성하는 것은 그 사용 범위나 목적이 특정한 상황에 한정되기 때문일 수 있습니다.
스프링 빈으로 등록하여 사용할 경우, 스프링 컨테이너가 관리하게 되므로, 애플리케이션의 다른 부분에서도 해당 빈을 주입받아 사용할 수 있는 이점이 있습니다. 하지만, 애플리케이션 전반에 걸쳐 해당 로직이 필요 없거나, 특정 설정이나 컨디션에서만 사용되어야 한다면 직접 객체를 생성하여 사용하는 것이 더 명시적이고 관리하기 쉬울 수 있습니다.
물론, 이러한 선택은 개발자의 선호도, 애플리케이션의 구조와 요구 사항, 유지 보수성 등 여러 요인을 고려하여 결정됩니다. 따라서 RestAuthenticationEntryPoint
와 RestAccessDeniedHandler
를 스프링 빈으로 등록하여도 잘 동작하는 경우는 해당 컴포넌트들이 애플리케이션 전역에서 일관된 방식으로 사용되어야 할 때 유용합니다.
제공해주신 코드 스니펫에서는 이러한 구성 요소들을 스프링 빈으로 명시적으로 등록하는 방식을 선택하셨고, 잘 동작하는 것으로 보아 애플리케이션의 요구 사항에 부합하는 구현 방법을 선택하신 것으로 판단됩니다. 상황에 따라 가장 적절한 방법을 선택하는 것이 중요합니다.
아하 감사합니다. 선생님