그날그날 공부기록

231218 ArgumentResolver argument resolver는 요청의 메서드 파라미터를 인자값으로 변환하기 위한 전략 인터페이스이다. 인터페이스에는 아래와 같이 2개의 메서드가 있다. public interface HandlerMethodArgumentResolver { boolean supportsParameter(MethodParameter parameter); @Nullable Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer, NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) thr..

231218 필터, 인터셉터 애플리케이션의 여러 로직에서 공통으로 관심이 있는 것 → 공통 관심사(cross-cutting concern) ex) 글 작성, 수정, 삭제, 덧글 작성 등의 유저 인증 여부 이런 공통 관심사는 스프링 AOP로도 해결할 수 있지만, 웹과 관련된 공통 관심사는 서블릿 필터 혹은 스프링 인터셉터를 사용하는 것이 좋다고 한다. 서블릿 필터나 스프링 인터셉터는 HttpServletRequest를 제공하기 때문. 서블릿 필터 필터를 사용한 요청의 흐름은 다음과 같다. 만약 적절하지 않은 요청이 올 경우, 필터에서 요청을 종료시켜 서블릿까지 넘기지 않을 수 있다. Http Request → WAS → Filter → Servlet → Controller 또, 필터는 체인으로 구성되어 여..

231126 쿠키, 세션 회원의 로그인 정보를 유지시켜야 하는 상황. 홈 → 로그인 → 메인 페이지 이동(홈) 우선 쿠키에 사용자 정보를 보관해 보자. 다음은 로그인 컨트롤러의 login 메서드이다. @PostMapping("/login") public String login(@Valid @ModelAttribute LoginForm form, BindingResult bindingResult, HttpServletResponse response) { if (bindingResult.hasErrors()) { return "login/loginForm"; } Member loginMember = loginService.login(form.getLoginId(), form.getPassword()); if..

스프링 시큐리티 설정 @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .formLogin().disable() .httpBasic().disable() .csrf().disable() .headers().frameOptions().disable() .and() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeHttpRequests() .requestMatchers("/", "/css/**", "/images/**", "/js/**", "/favicon.ico", "/h2-conso..

스프링을 통해 초기화 작업과 종료 작업을 어떻게 할 수 있을까? 생성자는 객체의 필수적인 데이터를 파라미터로 받아 객체를 생성하는 역할이다. 따라서 생성자를 통해 입력받은 필수 데이터로 수정자를 사용하여 객체를 초기화 하는것이 유지보수 관점에서 유리하다고 한다. 객체의 생성과, 초기화의 구분이 명확하기 떄문이다. 스프링 빈은 객체 생성 후 의존관계 주입을 한다. 그리고 의존관계 주입이 종료된 후 필요한 데이터를 사용할 수 있는 준비가 완료된다.(수정자를 사용한다면) 그렇다면 의존관계 주입이 종료됬다는걸 어떻게 알 수 있을까? 스프링은 의존관계 주입이 종료된 후 빈에게 콜백 메서드를 통해 어떠한 “시점"을 알려준다.(의존관계 주입이 끝나는 시점이나, 스프링 컨테이너가 종료되는 시점) 따라서 이런 콜백 메서..

지금까지 했던 예제 코드에서는 하나의 빈을 필드에 주입받아 사용했다. 하지만 여러 개의 빈을 주입받아 사용해야 한다면 어떻게 해야 할까? 예를 들어 여러 개의 할인방식(bean) 중 하나를 유저가 선택해야 하는 상황이라면 관련 빈들을 모두 가져와 컴파일 시점이 아닌 실행 시에 동적으로 할인 방식을 선택해야 한다. 고정 할인방식인 fixDiscount와 비율 할인방식인 rateDiscount가 있다고 생각해보자. @Component public class FixDiscountPolicy implements DiscountPolicy{} @Component public class RateDiscountPolicy implements DiscountPolicy{} 두 개의 빈은 모두 스프링 컨테이너에 등록이 ..

@Qualifier(”빈 이름")을 통해 필드와 빈을 매칭 할 수 있다. 하지만 컴파일시 타입이 체크되지 않는다. 이 경우 직접 @Qualifier(”빈 이름")을 포함하는 애노테이션을 직접 만들어 사용하면 해결할 수 있다. 자바 인터페이스 파일을 생성하여 @를 붙여주거나 클래스 파일을 하나 생성하여 public class → public @interface로 바꿔준다. @Qualifier를 대체할 애노테이션을 만들어야 하므로 ⌘ + O 단축키로 @Qualifier를 검색하여 원래 있던 애노테이션을 복사하여 추가한다. 그 후 기존에 @Qualifier(”빈 이름")으로 매칭해주었던 애노테이션을 추가해준다. 최종 코드는 다음과 같다. //@Qualifier에 있던 애노테이션 시작 @Target({Eleme..

@Autowired를 사용하여 빈을 조회하면 타입이 기준이 된다. 의존관계를 주입받을 경우 DIP를 위해 구현 객체가 아닌 인터페이스를 사용한다. 하지만 2개 이상 빈의 타입이 같으면 오류가 발생한다. 다음과 같이 할인을 위한 DiscountPolicy 인터페이스와 구현 객체가 2개 있다고 생각해보자. 두 객체 모두 @Component를 작성해 스프링 빈으로 스캔되고 등록된다. 이 상황에서 어떤 서비스에서 상위 타입인 DiscountPolicy로 의존관계를 주입받게 된다면 같은 타입의 빈이 2개가 되기 때문에 NoUniqueBeanDefinitionException오류가 발생한다. Caused by: org.springframework.beans.factory.NoUniqueBeanDefinitionEx..