Backend 96

스프링 - Controller에서 요청 데이터 받기

Spring Boot에서 Controller에서 요청 데이터를 받는 방법은 여러 가지가 있습니다. 아래는 주요 방법들과 예시 코드를 소개합니다. 1. @RequestParam - 쿼리 파라미터나 폼 데이터 받기 @RequestParam은 주로 GET 요청의 쿼리 파라미터나 POST 요청의 폼 데이터를 처리할 때 사용됩니다. @GetMapping("/greeting") public String greeting(@RequestParam(name = "name", required = false, defaultValue = "World") String name, Model model) { model.addAttribute("name", name); return "greeting"; } 2. @PathVariab..

서블릿(Servlet), WAS

서블릿(Servlet) Java를 사용하여 웹 서버에서 실행되는 프로그램을 작성하기 위한 기술이다. 서블릿은 클라이언트의 요청을 처리하고, 그결과를 클라이언트에게 다시 보내는 역할을 한다. WAS를 직접 구현하는 경우 순서 내용 1 서버 TCP/IP 연결 대기, 소켓 연결 : 클라이언트의 연결 요청을 대기하고 소켓을 통해 연결 2 HTTP 요청 메시지를 파싱해서 읽기: 클라이언트로부터 받은 HTTP 요청을 메시지로 파싱하여 읽는다. 3 POST 방식, /save URL 인지: HTTP 요청메서드가 무엇인지, 요청 URL의 경로를 인지하는 작업 4 Content-Type 확인 5 HTTP 메시지 바디 내용 파싱 예를 들어 JSON 형식의 데이터를 Java 객체로 파싱하는 작업 6 저장 프로세스 실행 7 비..

컴포넌트 스캔의 필터 활용 - Spring

컴포넌트 스캔의 필터 활용 includeFilters : 포함할 필터 excludeFilters : 불포함할 필터 우선 사용자 정의 에너테이션을 하나 만든다. @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface MyExcludeComponent { } and @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface MyIncludeComponent { } 위에 붙은 여러 가지의 에너테이션은 @Component의 소스코드에서 가져온 것 그 다음에 빈이 될 클래스에 해당 어노테이션을 붙인다...

의도적으로 동일 타입의 스프링 빈이 다 필요한 경우 - Spring

의도적으로 동일 타입의 스프링 빈이 다 필요한 경우 public class AllBeanTest { @Test @DisplayName("타입의 모든 빈 찾기") void findAllBean(){ ApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class); // AutoConfigApp도 등록한 이유는 아래 DiscountService는 본인만 스프링빈이기 때문에 // DiscountPolicy 타입 빈을 가져오려면 빈을 포함하고 있는 AutoAppConfig도 같이 빈으로 등록해준다. DiscountService discountService = ac.getBean(Disc..

같은 타입 빈이 여러 개인 경우 - Spring

조회 대상 빈이 2개 이상일 때 해결 방안 @Autowired 필드명 매칭 Quilifier -> @Quilifier끼리 매칭 -> 빈이름 매칭 @Primary 사용 @Autowired 필드명 매칭 예시 코드 @Autowired public OrderServiceImpl(ClientRepository clientRepository, DiscountPolicy discountPolicy) { this.clientRepository = clientRepository; this.discountPolicy = discountPolicy; } 예시 상황 discountpolicy의 구현체인 정률과 정액 할인이 빈에 등록됐다고 가정해보자 이 경우에는 오류가 발생할 것이다. (위 생성자에서 DiscountPolicy..

사용자 정의 애노테이션 - Spring

사용자 정의 애노테이션 사용자 정의 애노테이션을 만드는 이유? @Qualifier("") 에너테이션 안에 들어가는 문자열은 컴파일 시점에서 문자열 인식이 안되는 문제가 있을 수 있다. 또는 문자를 잘못 입력해도 오류가 발생할 수 있다. 이럴때 사용자 정의 애노테이션을 만들어서 코드의 정확성을 높이는 방법을 활용할 수 있다. @Qualifier 에노테이션 만들기. shift+shift 하면 여러가지 소스파일을 검색할 수 있음. 여기서 @Qualifier 검색 Qualifier의 소스코드를 보면 여러가지 에너테이션으로 만들어진 것을 볼 수 있다. 여러 에너테이션들을 복사해서 만드려는 에너테이션에 그대로 복사. 그리고 Qualifier를 마지막에 붙여줌. 에노테이션 직접 만들기 @Target({ElementT..

Spring / ComponentScan의 탐색 위치와 기본 스캔 대상

ComponentScan의 탐색 위치와 기본 스캔 대상 @ComponentScan(basePackages = {"hello.test1", "hello.test2"}) 지정하는 패키지의 하위 패키지만을 스캔한다. 지정 하지 않으면 현재 위치 패키지의 하위 패키지를 다 스캔하기 때문에 필요하다면 지정한다. 즉, @ComponentScan이 붙은 설정 정보 클래스의 패키지가 스캔의 시작 위치가 됨. 위 예시는 hello/text1 패키지와 test2 패키지의 하위 패키지만을 스캔 권장 방법은 애초에 구성 설정 클래스는 프로젝트를 대표하는 정보이므로, 프로젝트 시작 root에 위치 시켜 놓고, bassPackages 지정은 생략하는 것이 최근 관례 @SpringBootApplication SpringBoot 프..

Spring / 컴포넌트 스캔에서 빈을 중복으로 등록하는 상황과 충돌

컴포넌트 스캔에서 빈을 중복으로 등록하는 상황과 충돌 자동 빈 등록 (ComponentScan) 수동 빈 등록 (@Bean) 컴포넌트 스캔에 의해 자동으로 중복된 이름의 스프링 빈이 등록되면? ConflictingBeanDefinitionException 예외가 발생 수동 빈 등록과 자동 빈 등록이 충돌 되었다면? 예외가 발생하지 않는다. 이 경우, 수동 빈 등록이 우선권을 가진다. 수동 빈이 자동 빈을 오버라이딩 해버림. 테스트 코드를 보면 오버라이딩 했고 replace됐다는 것을 확인 할 수 있음. 그러나 이 것은 큰 버그를 야기할 수 있다. 따라서 최근의 스프링 부트는 수동 빈 등록과 자동 빈의 충돌 발생 시 오류가 발생하도록 기본 값을 바꿈. @SpringBootApplication 클래스를 실행..

Spring / 컴포넌트 스캔과 의존관계 자동 주입 (ComponentScan)

컴포넌트 스캔과 의존관계 자동 주입 등록해야 할 빈(@Bean)이 몇백 몇천개라면? 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔 기능을 제공 의존 관계도 자동 주입하는 @Autowired도 제공 @ComponentScan 자동으로 스프링 빈을 끌어올리는 에너테이션 즉 자동으로 스프링 빈을 등록해줌 이 에너테이션은 @Component 에너테이션이 붙은 클래스를 모두 스캔해서 스프링 빈으로 등록 @ComponentScan( excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class) ) 스프링 빈을 자동 등록하는데 필터링 할 것을 지정 컴포넌트 스캔을 지정하면 @..

Spring / 의존성 주입(생성자 주입이 권장되는 이유)

생성자 주입을 선택해야 하는 이유 최근에 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 권장한다. 불변성 대부분의 의존 관계 주입은 한번 일어나면 종료시점까지 의존관계를 변경할 일이 없음. 또한, 오히려 의존 관계는 애플리케이션 종료 전까지 불변해야 한다. (변경이 적어야함.) 수정자 주입은 setter를 public으로 열어 두어야 하기 때문에 외부에서 변경 가능성이 있음. 생성자 주입은 객체 생성 시 단 1번만 호출 되므로 불변하게 설계할 수 있음. 누락의 방지 생성자는 호출 시 필수적으로 값을 초기화해주어야 하므로, 누락을 방지할 수 있다. 또한 필드에 final을 붙여서 생성자에서만 초기화가 가능해지고 필드의 값이 final이므로, 불변성이 된다. 이 뿐만 아니라, 필드에 final이 붙..