인프런 커뮤니티 질문&답변

배성환님의 프로필 이미지

작성한 질문수

스프링 시큐리티 완전 정복 [6.x 개정판]

Rest 예외 처리 - RestAuthenticationEntryPoint / RestAccessDeniedHandler

Rest 예외 처리 - RestAuthenticationEntryPoint / RestAccessDeniedHandler 스프링빈 등록 질문

해결된 질문

작성

·

241

0

안녕하세요 선생님

Rest 예외처리 편에서 선생님께서는 RestAuthenticationEntryPoint 와 RestAccessDeniedHandler을 따로 스프링 빈으로 등록하지 않고 객체를 생성하는식으로 하셨는데 제가 따로 스프링빈으로 등록하고 해도 잘 동작하던대 따로 빈으로 등록하지 않고 하신 이유가있을까요?
해당 코드는 제가 빈으로 따로 등록하고 테스트 했던 코드입니다.

답변 2

0

정수원님의 프로필 이미지
정수원
지식공유자

자주 듣는 질문인데 사실 빈으로 정의하든 일반객체로 정의하든 둘다 문제 없습니다

선택의 문제입니다

빈으로 정의한다면 스프링 컨테이너가 관리하도록 하는 것 차이가 있습니다 즉 스프링의 여러 특화된 기능들을 사용할 수 있게 됩니다

그렇지 않다면 가벼운 일반객체로 생성해서 사용하시면 됩니다

배성환님의 프로필 이미지
배성환
질문자

아하 감사합니다. 선생님

0

안녕하세요, 인프런 AI 인턴입니다.

질문하신 RestAuthenticationEntryPointRestAccessDeniedHandler를 스프링 빈으로 등록하지 않고 직접 객체를 생성하여 사용하는 방식에 대해서는 여러 가지 이유가 있을 수 있습니다. 주된 이유 중 하나는 특정 구성이나 상황에서만 사용되는 커스텀 로직을 분리하여 관리하기 위함일 수 있습니다. 즉, 이들을 직접 생성하고 구성하는 것은 그 사용 범위나 목적이 특정한 상황에 한정되기 때문일 수 있습니다.

스프링 빈으로 등록하여 사용할 경우, 스프링 컨테이너가 관리하게 되므로, 애플리케이션의 다른 부분에서도 해당 빈을 주입받아 사용할 수 있는 이점이 있습니다. 하지만, 애플리케이션 전반에 걸쳐 해당 로직이 필요 없거나, 특정 설정이나 컨디션에서만 사용되어야 한다면 직접 객체를 생성하여 사용하는 것이 더 명시적이고 관리하기 쉬울 수 있습니다.

물론, 이러한 선택은 개발자의 선호도, 애플리케이션의 구조와 요구 사항, 유지 보수성 등 여러 요인을 고려하여 결정됩니다. 따라서 RestAuthenticationEntryPointRestAccessDeniedHandler를 스프링 빈으로 등록하여도 잘 동작하는 경우는 해당 컴포넌트들이 애플리케이션 전역에서 일관된 방식으로 사용되어야 할 때 유용합니다.

제공해주신 코드 스니펫에서는 이러한 구성 요소들을 스프링 빈으로 명시적으로 등록하는 방식을 선택하셨고, 잘 동작하는 것으로 보아 애플리케이션의 요구 사항에 부합하는 구현 방법을 선택하신 것으로 판단됩니다. 상황에 따라 가장 적절한 방법을 선택하는 것이 중요합니다.