@CrossOrigin CORS and Spring 서로 다른 origin 간의 리소스를 공유하기 위해서는 CORS 정책이 필요 CORS 정책을 사용하기 가장 좋은 방법은 서버에서 Access-Control-Allow-Origin 필드를 헤더에 추가해서 응답으로 보내면 됨 Spring에서는 여러 가지 방식으로 CORS 설정을 지원 @CrossOrigin 어노테이션 응답을 반환하는 메소드에 @CrossOrigin 어노테이션을 붙이면 모든 도메인에 대해 요청을 허용함 특정 도메인만 허용하고 싶다면 다음과 같이 사용 @CrossOrigin(origins = "A") @CrossOrigin(origins = {"A", "B"}) References https://velog.io/@modsiw/Spring-CrossOrigin-Annotation-%EC%A0%95%EB%A6%AC

Split Error Split Error public class ponitTest { public static void main(String[] args) throws Exception { String s = "abc.def.ghi"; String[] nums = s.split("."); System.out.println(nums[1]); } } split을 위와 같이 사용하는 경우 ArrayIndexOutOfBoundsException를 발생시킴 이유는 .이 정규식에서 사용하는 예약어기 때문 문자 그대로 .을 기준으로 나누고 싶다면 split("\\.")를 사용해야 함 다른 정규식 예약어들에도 해당 (^, ?, * 등) References https://baekh-93.tistory.com/72

Scope ProxyMode Scope ProxyMode Singleton 빈은 스프링이 시작될 때 생성됨 그러나 prototype 혹은 request 등의 스코프를 가진 빈들은 요청이 와야 생성됨 Singleton 빈 내부에서 이런 빈을 사용할 때 문제가 생김 이 경우에는 Provider를 이용할 수도 있지만, 다음과 같은 어노테이션을 붙여서 Proxy를 활용 가능 @Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS) 인터페이스인 경우 TARGET_CLASS 대신 INTERFACES로 치환 이 경우 가짜 프록시 빈을 미리 주입해 두고, 실제 요청이 오면 진짜 빈을 요청하게 됨 클라이언트는 싱글톤 빈을 사용하듯이 다른 scope를 사용 가능 그렇다 해도 무분별한 사용은 금지 실제 요청까지 객체 조회를 지연한다는 점이 핵심 아이디어 References 스프링 핵심 원리 기본편 - 김영한 (https://www.

Prototype Scope Scope Spring에서 scope란 빈이 존재할 수 있는 범위를 의미 각 bean은 다음과 같은 scope를 가짐 Singleton: 기본 스코프 Prototype 웹 관련 scope들 Prototype Prototype scope를 가진 빈은 굉장히 짧은 scope를 가짐 Spring container가 빈의 생성 및 의존 관계 주입까지만 관여하고 더는 관리하지 않음 이후 이 프로로타입 빈은 클라이언트에게 책임이 있고, @PreDestroy 등의 종료 메소드를 호출 불가 Bean에 @Scope("prototype") 어노테이션을 붙여 적용 가능 싱글톤과의 차이점 싱글톤 빈은 여러 요청에 따라 항상 같은 인스턴스의 빈을 반환 프로토타입 빈은 클라이언트가 요청할때마다 새로운 인스턴스를 생성해서 반환 프로토타입 빈을 싱글톤 빈 내부에서 그냥 사용하면 싱글톤처럼 사용됨 이 경우 Provider를 통해 문제를 해결 가능 References 스프링 핵심 원리 기본편 - 김영한 (https://www.

Bean LifeCycle Bean LifeCycle 스프링 빈은 다음과 같은 생명 주기를 가짐 Spring container 생성 Spring bean 생성 의존관계 주입 초기화 콜백 Bean 사용 소멸전 콜백 Spring 종료 초기화 콜백을 이용해 객체의 초기화를 수행 가능, 객체의 생성과 초기화가 분리됨 소멸전 콜백으로 객체가 소멸되기 전에 수행해야 하는 작업을 수행 가능 다음과 같은 세 가지 방법을 통해 초기화 콜백, 소멸전 콜백을 이용 가능 InitializingBean, DisposableBean 인터페이스 설정 정보를 활용 @PostConstruct, @PreDestroy 어노테이션 InitializingBean, DisposableBean 인터페이스 Spring bean이 InitializingBean 인터페이스를 구현 시 afterPropertiesSet() 메소드를 오버라이딩해서 초기화 콜백 이용 가능 DisposableBean 인터페이스를 구현 시 destroy() 메소드를 오버라이딩해서 소멸전 콜백 이용 가능 다음과 같은 단점들 때문에 잘 사용되지 않음 메소드 이름이 고정됨 Spring 전용 인터페이스므로 코드가 spring에 의존 외부 라이브러리에 사용 불가 설정 정보를 활용 설정 정보에서 @Bean(initMethod = "init")을 사용 시 클래스 내의 init() 함수가 초기화 콜백으로 호출 됨 @Bean(destroyMethod = "close") 을 사용 시 클래스 내의 close() 함수가 소멸전 콜백으로 호출 됨 메소드 이름이 고정되지 않고, spring에 의존하지 않으며, 외부 라이브러리에 사용 가능 @PostConstruct, @PreDestroy 어노테이션 클래스 내의 함수에 @PostConstruct 어노테이션을 붙이면, 해당 함수가 초기화 콜백으로 호출 됨 @PreDestroy 어노테이션을 붙이면, 해당 함수가 소멸전 콜백으로 호출 됨 최신 스프링에서 가장 권장되고, 가장 쉽고 간편한 방법 다만 외부 라이브러리의 경우 수정이 불가능.

@Qualifier @Primary Duplicate Bean @Autowired로 의존 관계 주입을 자동으로 실행할 때, 타입으로 조회하게 됨 해당 타입의 bean이 하나가 아닐 수도 있고, 이 경우 NoUniqueBeanDefinitionException이 발생 @Qualifier 혹은 @Primary 어노테이션을 이용해 해결 가능 @Qualifier @Qualifier 라는 추가적인 어노테이션을 붙여서 의존 관계를 주입할 대상 선택 다음 예시에서는 CA 빈이 선택됨 @Primary보다 우선권이 높음 @Component @Qualifier("A") public class CA implements SomeInterface {} @Component @Qualifier("B") public class CB implements SomeInterface {} @Component public class C { private final SomeInterface i; @Autowired public C(@Qualifier("A") SomeInterface i) { this.

Lombok RequiredArgsConstructor Lombok RequiredArgsConstructor 대부분의 경우 spring bean의 필드는 불변이고, final 키워드로 선언됨 이 때 생성자를 통해 의존성을 주입받는 코드를 매 번 삽입하기에는 너무 길고, 변경이 비교적 힘듦 이 때 Lombok의 RequiredArgsConstructor 어노테이션을 활용 가능 final 필드에 대한 생성자를 자동으로 생성해 줌 기존 코드 생성자가 필요. @Autowired는 생략 가능 @Component public class A implements I { private final int field1; private final int field2; @Autowired public A(int f1, int f2) { this.

@Autowired @Autowired 스프링에서 의존 관계를 자동으로 주입해주는 어노테이션 의존 관계를 설정하는 별도의 설정 파일이나 과정이 필요 없음 스프링 컨테이너가 직접 타입에 해당하는 스프링 빈을 찾아서 주입하는 방식 생성자, 수정자 (Setter) 혹은 필드에 붙는 어노테이션 기본 값이 required=true. 즉, 의존성을 주입할 스프링 빈이 없는 경우 오류 발생 @Autowired(required=false)로 사용하면 해당하는 스프링 빈이 없는 경우 호출되지 않음 References 스프링 핵심 원리 기본편 - 김영한 (https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard) https://devlog-wjdrbs96.tistory.com/166

Dependency Injection Methods Dependency Injection Methods 의존 관계 주입은 다음과 같이 네 가지 방법으로 수행 가능 생성자 주입 수정자(setter) 주입 필드 주입 일반 메서드 주입 각 주입 방식마다 장단점이 존재 최근 대부분의 DI 프레임워크에서는 생성자 주입 사용 생성자 주입 객체가 생성될 때, 생성자를 통해 의존 관계를 주입받는 방법 생성자 호출은 한 번만 되므로, 무조건 한 번만 실행된다는 것이 보장됨 필수적이며, 변하지 않는 의존 관계에 주로 사용 대부분의 의존 관계는 변하면 안되는 경우가 많으므로, 생성자 주입이 적극 권장됨 이 방법만 필드에 final 키워드를 사용 가능 Spring bean의 경우 생성자가 1개만 있으면 @Autowired를 생략해도 됨 예제 코드 public class A { private final SomeInterface i; @Autowired public A(SomeInterface i) { this.

Sort Lambda Sort Lambda 자바에서는 Arrays.sort 혹은 Collections.sort 함수를 통해 배열 및 리스트 등의 정렬을 수행 가능 정렬하는 대상이 primitive type 혹은 comparable 인터페이스를 구현한 경우, 별도의 정렬 함수 없이 정렬 가능 그러나 다음과 같은 경우에는 직접 정렬 함수를 넣어줘야 함 별도의 기준으로 정렬하고 싶을 때 comparable 인터페이스가 구현되지 않은 클래스의 객체들을 정렬할 때 Java 8부터는 람다 문법을 지원하므로, 정렬 함수 자리에 람다식을 넣으면 간단하게 표현 가능 예시 다음은 string을 길이 순으로 정렬하고, 길이가 같은 경우 사전 순으로 정렬하는 예시 String[] words = new String[N]; Arrays.