spring (10) 썸네일형 리스트형 @Async 예외처리 @Async 를 사용해서 여러 스레드로 작업을 돌리다가, 한 스레드에서 에러가 나게 되면 그 스레드만 아무 notice 없이 죽게 된다. 하지만 우리는 이런 예외 상황도 알고 싶은 경우가 많다. 결론 부터 말하면, 비동기로 처리할 메서드의 return 이 있냐 없냐에 따라 다르다. 1. return 이 없는 경우 테스트 해 볼 서비스는 아래와 같다. @Service class AsyncServiceImpl { @Async fun asyncTask(x: Int) { for (y in listOf(10, 20, 30)) { Thread.sleep(1000) res += x * y if (x * y == 90) throw IllegalArgumentException("에러 !! 에러 !!") println(".. kotlin 마스킹 해당 글은 Meet-Coder 에서 블로그 포스팅 스터디를 하면서 쓴 글입니다. MarkDown 으로 쓴 글이기에, 해당 tstroy 보다는 아래 github repository 에서 보는 것이 깔끔합니다. https://github.com/cmg1411/posting-review/blob/master/kimmingeor/2021-11-13-masking.md GitHub - cmg1411/posting-review: 📝 블로그 포스팅 스터디 리뷰 저장소 📝 블로그 포스팅 스터디 리뷰 저장소. Contribute to cmg1411/posting-review development by creating an account on GitHub. github.com 이전에 스터디에서 Interceptor 에서 .. spring interceptor 해당 글은 Meet-Coder 에서 블로그 포스팅 스터디를 하면서 쓴 글입니다. MarkDown 으로 쓴 글이기에, 해당 tstroy 보다는 아래 github repository 에서 보는 것이 깔끔합니다. https://github.com/cmg1411/posting-review/blob/master/kimmingeor/2021-10-30-interceptor.md GitHub - cmg1411/posting-review: 📝 블로그 포스팅 스터디 리뷰 저장소 📝 블로그 포스팅 스터디 리뷰 저장소. Contribute to cmg1411/posting-review development by creating an account on GitHub. github.com 출처 : https://bgpark.t.. 빈 스코프 Scope 라는 단어는 범위 정도로 해석할 수 있을 것 같다. 변수 스코프란, 그 변수가 유효한 범위를 의미하듯이. 그런 의미로 스프링에서 빈 스코프는 빈이 유효한 범위 즉 라이프사이클의 범위를 의미한다. 스프링 빈은 기본적으로 싱글톤으로 생성되어 스프링 컨테이너가 생성되고 종료될때까지이다. 오늘 공부해볼 스프링의 빈 스코프는 싱글톤 스코프를 포함하여 세가지이다. 싱글톤 : 스프링 컨테이너가 뜨고 종료될때까지 빈이 유지되는 스코프. 가장 넓은 범위이다. 프로토타입 : 빈의 라이프사이클중 빈의 생성, 등록, 주입, 초기화까지만의 스코프를 가진다. 웹 관련 스코프 request : 웹 요청이 들어오고 나갈때까지의 스코프를 가진다. session : 세션이 생성되고 종료될 때까지의 스코프를 가진다. appli.. 스프링 빈의 생명주기와 초기화 분리 스프링 빈도 객체이기 때문에 초기화가 필요할 것이다. 그리고 우리는 이 초기화를 보통 생성자에서 처리하게 된다. 필드같은 간단한 초기화는 괜찮지만, 만약 데이터베이스의 커넥션풀을 미리 셋팅하는 것과 같은 무거운 작업들은 ? 소켓 통신을 위해 소켓을 미리 열어두는 초기화 작업들은 ? 객체의 생성과 초기화는 분리해야한다. 객체의 생성과 객체의 초기화는 다른 책임이다. SRP 의 원칙에 따라 이 두 로직은 분리되는 것이 좋다. 물론 간단한 필드 한두개를 초기화하는 데에 생성자를 쓰지 않고 따로 하는 것은 비효율적일 수 있지만, 위의 예인 커넥션풀처럼 무거운 초기화 작업들은 분리하는 것이 좋다. 오늘은 이 초기화라는 작업을 스프링에서 어떻게 분리하여 처리하게 도와주는지 알아본다. 스프링 컨테이너를 사용해 빈을 .. 자동 주입시 빈이 2개 이상일 때 문제 해결 @Autowired 는 타입으로 빈을 조회한다. 또, 스프링의 객체지향적 인 코드를 짜기 위해 우리는 인터페이스와 스프링 컨테이너를 이용하여 DIP, OCP 를 만족시킨다. 그런데, 스프링에서 @Autowired 로 빈을 주입하기 위해 getBean 메서드와 같이 빈을 조회할 때에는 생성자, 수정자 주입시 매개변수의 파라미터, 필드 주입시 필드의 타입을 보고 해당 타입의 하위 타입을 모두 가져오게 된다. 그런데 만약 하위 타입들 중 @Component 로 등록된게 2개 이상이라면? 스프링은 오류를 뱉게 된다. 예를 들어 아래와 같은 서비스의 계층구조가 있다고 생각해보자. 그런데 AutoDrivingService, UserDrivingService 가 모두 빈에 등록된 것이다. 코드로 보면 대략 이럴 것이.. 생성자 자동 주입의 장점, @RequiredArgsConstructor 불변이다. 의존관계를 설정하는 부분과 시스템을 돌아가게하는 부분은 분리되어야 한다. (CleanCode) 변경 가능성을 최소화하라. (Effective Java) 수정자 주입을 사용하려면 setter 를 public 으로 열어야한다. 객체의 상태가 변경가능하면 문제가 생길 여지가 너무 많다. 생성자 주입은 빈이 등록되기위해 싱글톤 객체가 생성될 때 딱 한번만 주입하고 변경하지 않는다. 테스트의 편함 수정자 주입에서는 의존관계가 무엇이 있었는지 있긴 한지는 코드의 setter 를 까봐야한다. 또한 런타임에 에러가 나게 된다. 생성자 주입은 생성자의 매개변수로 주지 않으면 애초에 컴파일에러가 난다. 또, IDE 의 도움을 받으면 코드 작성시 매개변수를 볼 수 있다. final 생성자 주입방식을 쓰면 fina.. @Autowired @Autowired 이 에너테이션은 스프링 컨테이너에 등록된 빈들 중에서 타입이 일치하는 빈을 찾아와 자동으로 주입시킨다. 생성자 주입 생성자 호출 시점에 한번만 주입됨이 보장된다. 의존관계를 처음 셋팅할 때 한번만 설정하고 이후에는 변경하고 싶지 않을때. 의존 객체가 불변이 된다. (final 도 붙이자.) final 이 붙은 필드는 초기화가 무조건 필요하다. (하지 않으면 컴파일타임에 에러남) 생성자 주입이니 생성자에서 초기화해주며, 필수값임을 나타낼 수 있다. 생성자가 하나라면, @Autowired 를 생략할 수 있다. 생성자 오버로딩으로 두개 이상이라면 어떤 것을 의존관계 설정에 이용할 것인지 모르기 떄문에 생략하면 안되고 지정해줘야한다. 수정자(Setter) 주입 선택적이다. 주입을 해도 되고 .. 이전 1 2 다음
