softwareNote

[오류 기록] Custom WebSecurityConfigurerAdapter가 적용되지 않음

haileykim1 — Sun, 26 Jun 2022 07:32:01 +0900

문제

WebSecurityConfigurerAdapter을 상속받은 SecurityConfig 클래스에서 configure 메서드를 오버라이딩하여 인증을 선택적으로 적용하였다.

"/" 은 permitAll을 적용한 url중 하나인데 /페이지에 접속하면 인증을 요구하였다.

원인

SecurityConfig 클래스가 포함된 oauth2 패키지가 @SpringBootApplication을 포함하고 있는 DeveloperCommunityApplication.kt 파일을 포함하는 프로젝트 패키지에 포함되어 있지 않았다.

따라서 ComponentScan의 적용 대상이 되지 않았다.

시도한 해결방법

oauth2 패키지를 developercommunity 패키지(프로젝트 패키지) 하위로 옮겼다.

(애초에 왜 밖에다 만들었는지 모르겠음. 실수인 것 같다)

해결 여부

해결 완료

Reference

https://stackoverflow.com/questions/43868329/custom-security-is-not-working-when-extending-the-websecurityconfigureradapter-c

Custom security is not working when extending the WebSecurityConfigurerAdapter class in different package

I have extendend WebSecurityConfigurerAdapter in a different package other than the package containing class for @SpringBootApplication. Then it's not working its generating default username and pa...

stackoverflow.com

CPU와 메모리

haileykim1 — Tue, 24 May 2022 16:48:09 +0900

CPU

CPU의 기본 구성

산술논리 연산장치 ALU(Arithmetic and Logic Unit)
: 데이터의 산술 연산(덧셈, 뺄셈, 곱셈, 나눗셈 등)과 논리연산(AND, OR 등) 수행한다.
제어장치 control unit
: CPU에서 작업을 지시하는 부분
레지스터 register
: CPU내의 데이터를 임시로 보관하는 곳

레지스터의 종류

가시 레지스터 user-visible register

: 사용자 프로그램에 의해 변경된다.

데이터 레지스터 data register (일반 레지스터, 범용 레지스터)
: 메모리에서 가져온 데이터를 임시로 보관할 때 사용한다.
주소 레지스터 address register
: 데이터 또는 명령어가 저장된 메모리의 주소가 저장된느 곳이다.

특수 레지스터

프로그램 카운터(PC)
: 다음에 실행할 명령어의 주소를 저장하는 레지스터이다.
명령어 레지스터(IR; instruction register)
: 현재 실행 중인 명령어를 저장한다.
메모리 주소 레지스터(MAR; memory address register)
: 메모리에서 데이터를 가져오거나 메모리로 데이터를 보낼 때 주소를 지정하기 위해 사용한다.
메모리 버퍼 레지스터(MBR; memory buffer register)
: 메모리에서 가져온 데이터나 메모리로 옮겨 갈 데이터를 임시로 저장한다.
프로그램 상태 레지스터(PSR; program status register)
: 연산 결과(양수 음수 여부, 0인지 여부, 자리 올림 여부)를 저장한다.

MBR은 항상 MAR과 함께 동작한다.

버스의 종류

버스는 CPU와 메모리, 주변장치 간에 데이터를 주고 받을 때 사용한다.

버스에 실리는 정보는 제어 신호, 주소, 데이터이다.

각각 제어버스, 주소버스, 데이터 버스에 실린다.

1. 제어버스

다음에 어떤 작업을 할 지 지시하는 제어 신호가 오고간다.

ex) 읽기 신호, 쓰기 신호, 등

메모리에서 오류가 발생한 경우나 주변장치에 데이터가 도착했다는 신호 등도 CPU로 전달된다.

제어버스의 신호는 CPU, 메모리, 주변장치와 양방향으로 오고 간다.

2. 주소버스

메모리의 데이터를 읽거나 쓸 때 어느 위치에서 작업할 것인지를 알려주는 주소가 오고 간다.

주소버스는 MAR과 연결되어 있고 단방향이다.(CPU → 주변장치)

3. 데이터버스

데이터가 실려 목적지까지 이동하는 버스이다.

데이터 버스는 MBR와 연결되어 있으며 양방향이다.

버스의 대역폭

한 번에 전달할 수 있는 데이터의 최대 크기이다.

CPU가 한 번에 처리할 수 있는 데이터의 크기와 같다.

ex) 32bit, 64bit

메모리

모든 프로그램은 메모리에 올라와야 실행될 수 있다.

메모리 주소는 바이트 단위로 지정되고 메모리에서 데이터를 읽거나 쓸 때는 워드 단위로 움직인다.

메모리의 종류

램 Random Access Memory

: 읽거나 쓸 수 있는 메모리이다.

휘발성 메모리 volatility memory

DRAM (Dynamic Ram, 동적 램)
: 일정 시간이 지나면 사라지므로 일정 시간마다 다시 재생시켜야 한다.
SRAM (Static RAM, 정적램)
: 전력이 공급되는 동안에는 데이터를 보관할 수 있어 재생할 필요가 없다.
SDRAM (Synchronous Dynamic Random Access Memory)
: DRAM이 발전된 형태. 클록틱이 발생할 때 마다 데이터를 저장하는 동기 DRAM

비휘발성 메모리 non-volatility memory

플래시 메모리
플래시메모리의 각 소자는 최대 사용 횟수가 제한되어 몇 천번~만번 사용하면 기능을 잃는다.
FRAM Ferroelectric RAM
PRAM Phase change RAM

비휘발성 메모리는 내부가 복잡하고 속도가 느리고 가격이 비싸서 메인메모리는 휘발성 메모리를 사용한다.

롬 Read Only Memory

: 읽기만 가능한 메모리이다.

전력이 끊겨도 데이터를 보관한다.

데이터를 한 번 저장하면 바꿀 수 없다.

바이오스를 롬에 저장한다.

메모리 보호

CPU는 현재 진행 중인 작업의 메모리 시작 주소를 경계 레지스터(bound register)에 저장한 후 작업한다.

또 현재 진행중인 작업이 차지하고 있는 메모리의 크기를 한계 레지스터(limit register)에 저장한다.

작업이 진행되는 동안 이 두 레지스터의 주소 범위를 벗어나는지 하드웨어적으로 점검함으로써 메모리를 보호한다.

만약 두 레지스터 값을 벗어나면 메모리 오류와 관련된 인터럽트가 발생한다.

(인터럽트가 발생하면 모든 작업이 중단되고 CPU는 운영체제를 깨워서 인터럽트를 처리하도록 시킨다.)

부팅 과정

운영체제도 CPU에 의해 실행되는 프로그램이기 때문에 메모리에 올라와야 한다

부팅 booting : 컴퓨터를 켰을 때 운영체제를 메모리에 올리는 과정

사용자가 컴퓨터 전원을 키면 롬에 저장된 바이오스가 실행된다.
바이오스는 CPU, 메모리, HDD, 키보드, 마우스와 같은 주요 HW가 제대로 작동하는지 확인한다.
이상이 없으면 HDD의 마스터 부트 레코드(MBR)에 저장된 작은 프로그램을 메모리로 가져와 실행한다.
HDD에 저장된 운영체제를 메모리로 불러온다.

마스터 부트 레코드 : 하드 디스크의 첫번째 섹터. OS를 실행하기 위한 코드인 부트스트랩이 저장되어 있다.

부트스트랩 코드 : OS를 메모리로 가져와 실행하는 역할을 하는 작은 프로그램

[출처]

쉽게 배우는 운영체제

컴퓨터의 기본 구성 - 하드웨어 구성

haileykim1 — Tue, 24 May 2022 15:12:30 +0900

하드웨어 구성

필수 장치

중앙처리장치(CPU)
메인메모리(제1저장장치, first storage)

주변장치

입력장치
출력장치
저장장치(제2저장장치, second storage)

CPU와 메모리

CPU : 명령어를 해석하여 실행하는 장치.
메모리 : 작업에 필요한 프로그램과 데이터를 저장하는 장소.

입출력장치

입력장치 : 외부의 데이터를 컴퓨터에 입력하는 장치
ex) 키보드, 마우스, 스캐너
출력장치 : 컴퓨터에서 처리한 결과를 사용자가 원하는 형태로 출력하는 장치
ex) 프린터, 모니터, 스피커 등

저장장치

자성을 이용하는 장치 : 카세트테이프, 플로피디스크, 하드디스크 등
레이저를 이용하는 장치 : CD, DVD, 블루레이디스크 등
메모리를 이용하는 장치 : USB, SD 카드, CF 카드, SSD 등

메인보드

CPU와 메모리 등 다양한 부품을 연결하는 커다란 판이다.

부품끼리는 버스로 연결되어있다.

폰 노이만 구조 von Neumann architecture

오늘날 컴퓨터는 대부분 폰 노이만 구조를 따른다.

CPU, 메모리, 입출력장치, 저장장치가 버스로 연결되어있는 구조이다.
메모리를 이용하여 프로그래밍이 가능한 컴퓨터 구조이다.
모든 프로그램은 메모리에 올라와야 실행할 수 있다는 특징이 있다.

하드웨어 사양 관련 용어

클록 clock

CPU 속도와 관련된 단위

클록이 일정 간격으로 틱을 만들어 내면 거기에 맞추어 CPU안의 모든 구성 부품이 작업을 한다.

헤르츠 Hz

클록틱이 발생하는 속도를 말한다.

1초에 클록틱 한 번 = 1Hz

시스템 버스와 내부 버스

시스템 버스 = FSB(Front-Side Bus) : 메모리와 주변 장치를 연결하는 버스

CPU 내부 버스 = BSB(Back-Side Bus) : CPU 내부에 있는 장치를 연결하는 버스.

CPU의 클록과 같아서 시스템 버스보다 훨씬 빠르다.

[출처]

쉽게 배우는 운영체제

[Spring][Kotlin] 빈 스코프

haileykim1 — Sat, 21 May 2022 15:44:08 +0900

빈 스코프란?

빈 스코프는 빈이 존재할 수 있는 범위를 뜻한다.

스프링은 다양한 스코프를 지원한다.

싱글톤 : 기본 스코프. 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프
프로토타입 : 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프
웹 스코프
- request : 웹 요청이 들어오고 나갈때 까지 유지되는 스코프
- session : 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프
- application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프

빈 스코프는 다음과 같이 지정 가능하다

[컴포넌트 스캔 자동 등록]

@Scope("prototype")
@Component
class HelloBean{...}

[수동 등록]

class LifeCycleConfig{
	@Scope("prototype")
	@Bean
	fun helloBean = HelloBean()
}

프로토타입 스코프

싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환한다.

프로토타입 스코프의 빈을 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환한다.

그리고 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에게 반환한다.

이후에 같은 요청이 오면 새로운 프로토타입 빈을 생성해서 반환한다.

생성한 객체를 클라이언트에게 반환하고 더이상 관리하지 않기 때문에 이때부터 클라이언트가 빈을 관리해야한다.

-> @PreDestroy가 자동으로 호출되자 않는다.

프로토타입 빈과 싱글톤 빈 함께 사용 시 문제점

싱글톤 빈과 프로토타입 스코프의 빈을 함께 사용하면 잘 동작하지 않을 때가 있다.

아래에서 싱글톤 빈이 의존관계 주입을 통해 프로토타입 빈을 주입받아서 사용하는 예를 보자

clientBean은 싱글톤이므로 스프링 컨테이너 생성 시점에 함께 생성되고 의존관계 주입도 발생한다.

clientBean이 의존관계 자동 주입을 사용한다면 주입 시점에 스프링 컨테이너에 프로토타입 빈을 요청한다.

스프링 컨테이너는 프로토타입 빈을 생성해서 clientBean에 반환한다.

clientBean은 프로토타입 빈의 참조값을 내부 필드에 보관한다.

클라이언트가 싱글톤 빈인 clientBean을 스프링 컨테이너에게 요청해서 받고 그 내부의 프로토타입 빈을 이용해서 로직을 수행하는 상황이 있다.

클라이언트가 프로토타입 빈을 몇 번을 요청해도 이 프로토타입 빈은 모두 같은 객체이다(싱글톤 빈 내부의 저장된 참조값을 참고해 반환해주기 때문이다.)

따라서 새로운 객체라고 생각하고 사용하면 의도치 않는 동작이 일어난다.

프로토타입 스코프 : 싱글톤 빈과 함께 사용 시 Provider로 문제 해결

지금 필요한 기능은 지정한 프로토타입 빈을 컨테이너에서 찾아주는 DL기능이다.

DL : Dependency Lookup = 의존관계 탐색

스프링에는 이런 기능을 제공하는 것이 있다.

ObjectFactory, ObjectProvider

[ObjectProvider]

: getObject하면 그때서야 스프링 컨테이너에게 오브젝트 받아서 반환해주는 기능 제공(DL)

[ObjectFactory]

: getObject 기능 하나만 제공

ObjectProvider는 ObjectFactory 인터페이스를 상속받고 있다.

옵션, 스트림 처리 등 편의 기능이 많다.

별도의 라이브러리는 필요 없지만 스프링에 의존한다.

정리

사실 싱글톤 빈으로 대부분의 문제를 해결할 수 있다.

프로토타입 빈은 매번 사용할 때 마다 의존관계 주입이 완료된 새로운 객체 필요할 때 사용하면 된다.

스프링이 제공하는 기능와 자바 표준이 둘다 비슷한 기능을 제공한다면 다양하고 편리한 기능을 제공해주는 스프링을 쓰자.
다른 컨테이너를 쓸 일이 있다면 자바 표준을 쓰면 된다.

웹 스코프

웹 스코프는 웹 환경에서만 동작한다.

프로토타입 스코프와 다르게 스프링이 스코프의 종료시점까지 관리한다. -> 종료 메서드가 호출됨

request

HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프.

각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고 관리된다.

session

HTTP Session과 동일한 생명주기를 가지는 스코프

application

서블릿 컨텍스트(Servlet Context)와 동일한 생명주기를 가지는 스코프

websocket

웹 소켓과 동일한 생명주기를 가지는 스코프

P] 스프링 앱 실행 시점에 싱글톤 빈 생성해서 주입 가능하지만 request 빈은 실제 고객의 요청이 와야 생성이 가능하기 때문에 오류가 발생할 수 있다.

스코프와 Provider

Provider을 적용한다면 ObjectProvider.getObject()를 호출하는 시점까지 request scope 빈의 생성을 지연할 수 있다.

스코프와 프록시

프록시의 방법을 사용해 문제를 해결해보자.

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
class xxx{...}

적용 대상이 클래스면 TARGET_CLASS,
적용 대상이 인터페이스이면 INTERFACES를 선택

이렇게 프록시 방식을 사용하기만 하면 오류가 발생하지 않는다.

이유를 알아보자.

주입된 스코프 빈의 클래스 정보를 찍어보면 CGLIB 라이브러리로 만든 객체라는 것을 알 수 있다.

//클래스 정보 출력 결과
xxx = class soyang.hellocore.common.xxx$$EnhancerBySpringCGLIB&&~~~

@Scope의 proxyMode = ScopedProxyMode.TARGET_CLASS 를 설정하면 스프링 컨테이너는 CGLIB라는 바이트코드를 조작하는 라이브러리를 사용해서 xxx를 상속받은 가짜 프록시 객체를 생성한다.

그리고 스프링 컨테이너에 빈 이름으로 진짜 대신 가짜 프록시 객체를 등록한다.

(xxx 타입의 자식 타입이기 때문에 빈 조회시 조회 가능하다)

의존관계 주입도 이 가짜 프록시 객체가 주입된다.

가짜 프록시 객체는 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어있다.

(내부에 진짜 객체를 찾는 방법을 알고 있다.

클라이언트가 객체의 메서드를 호출하면 (이 객체는 프록시 객체이므로) 가짜 프록시 객체의 메서드가 호출되지만 이 가짜 프록시 객체가 request 스코프의 진짜 객체의 메서드를 호출한다.

클라이언트 입장에서는 원본인지 아닌지 모르게 동일하게 사용할 수 있다(다형성)

[출처]

스프링 핵심 원리 - 기본편

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

스프링 핵심 원리 - 기본편 - 인프런 | 강의

스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다., - 강의 소개 | 인프런...

www.inflearn.com

[Spring][Kotlin] 빈 생명주기 콜백

haileykim1 — Sat, 21 May 2022 14:18:46 +0900

빈 생명주기 콜백 시작

빈 생명주기 콜백은 빈이 생성될 때와 소멸하기 직전에 안전하게 처리될 수 있도록 호출하는 콜백이다.

DB 커넥션 풀이나 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면 객체의 초기화 + 종료 작업이 필요하다

서버 뜰 때 애플리케이션이랑 DB를 미리 10~100개정도 연결해놓는다.
고객 요청이 올 때 연결해놓을 걸 재활용할 수 있다.

스프링 빈은 간단하게 다음과 같은 lifeCycle을 가진다
객체 생성 -> 의존관계 주입
(예외 : 생성자 주입)

스프링 빈은 객체 생성 후 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다

-> 스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해 초기화 시점을 알려주는 다양한 기능을 제공한다 + 스프링이 종료되기 직전에 소멸 콜백을 호출시킨다.

=> 안전하게 초기화 + 종료 작업 진행이 가능하다

스프링 빈의 이벤트 라이프사이클(싱글톤 빈)
스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸 전 콜백 -> 스프링 종료

(생명주기가 짧은 빈들은 컨테이너와 무관하게 해당 빈이 종료되기 직전 소멸 전 콜백이 일어난다. 자세한건 스코프에서)

객체의 생성과 초기화는 분리하는 것이 좋다.
단일 책임 원칙을 지킬 수 있고, 초기화는 동작이랑 연관이 많기 때문이다.

스프링 빈 생명주기 콜백 지원방식은 3가지가 있다.

인터페이스(InitializingBean, DisposableBean)
설정 정보에 초기화 메서드, 종료 메서드 지원
@PostConstruct, @PreDestroy 애노테이션 지원

인터페이스 InitializingBean, Disposable Bean

인터페이스 InitializingBean, DisposableBean을 구현해서 사용한다.

초기화 메서드인 afterPropertiesSet과 소멸 메서드인 destroy를 override 하여 사용한다.

초기화, 소멸 인터페이스 단점

스프링 전용 인터페이스이므로 해당 코드가 스프링 인터페이스에 의존한다.
초기화, 소멸 메서드의 이름을 변경할 수 없다.
내가 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다.

이건 스프링 초창기에 나온 방법이고 지금은 더 나은 방법들이 있어서 거의 사용하지 않는다.

빈 등록 초기화, 소멸 메서드

설정 정보에 초기화, 소멸 메서드를 지정 가능하다

@Configuration
class LifeCycleConfig{

	@Bean(initMethod = "init", destroyMethod = "close")
    fun networkClient(): NetworkClient{...}

}

[특징]

메서드 이름을 자유롭게 설정 가능하다
스프링 빈이 스프링 코드에 의존하지 않는다.
코드가 아니라 설정 정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료 메서드 적용이 가능하다.(NetworkClient 코드 내부가 아니라 설정정보에서 메서드를 지정했다.)

종료 메서드 추론

@Bean의 destroyMethod는 default 값이 (inferred)이다.

라이브러리는 대부분 close, shutdown이라는 종료 메서드를 사용한다.

따라서 종료 메서드를 inferred(추론) 하여 close, shutdown이라는 이름의 메서드를 자동으로 호출해준다.

따라서 직접 스프링 빈으로 등록하면 종료 메서드는 따로 적어주지 않아도 잘 동작한다.

추론 기능을 사용하기 싫으면 destroyMethod = "" 로 지정해주면 된다.

애노테이션 @PostConstruct, @PreDestroy

이 방식을 주로 많이 사용한다.

최신 스프링에서 권장하는 방법이다.

매우 편리하고 컴포넌트 스캔과 잘 어울린다.

javax는 자바 진영에서 공식적으로 지원하는것이다.
꼭 스프링이 아니라 다른 컨테이너를 사용하더라도 적용 가능하다

class NetworkClient{


	...
	
    @PostConstruct
    fun init(){...}
    
    @PreDestroy
    fun close(){...}
    
}

@Configuration
class LifeCycleConfig{

	@Bean
    fun networkClient: NetworkClient{...}

}

단점 : 외부 라이브러리에 적용하지 못한다.

[출처]

스프링 핵심 원리 - 기본편

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

스프링 핵심 원리 - 기본편 - 인프런 | 강의

스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다., - 강의 소개 | 인프런...

www.inflearn.com

[Spring][Kotlin]의존관계 자동 주입

haileykim1 — Sat, 21 May 2022 13:26:45 +0900

다양한 의존관계 주입 방법

생성자 주입
수정자 주입(setter 주입)
필드 주입
일반 메서드 주입

생성자 주입

: 생성자를 통해서 의존관계를 주입받는 방법이다.

[특징]

생성자 호출 시점에 딱 한번만 호출되는 것이 보장 -> 그때 값 세팅하고 그 후 세팅 못하게 막기 가능하다
불변, 필수 의존관계에 사용

생성자가 딱 하나 있다면 @Autowired 생략 가능하다.
(스프링 빈인 경우)

@Component
class OrderServiceImpl: OrderService{

	val memberRepository: MemberRepository
    val discountPolicy: DiscountPolicy
    
    @Autowired
    constructor(memberRepository: MemberRepository, discountPolicy: DiscountPolicy){
    
    	this.memberRepository = memberRepository
        this.discountPolicy = discountPolicy
    }


}

수정자 주입

: 수정자 메서드 setter를 통해 의존관계 주입하는 방법이다.

[특징]

선택, 변경 가능성이 있는 의존관계에 사용
자바빈 프로퍼티 규약의 수정자 메서드 방식을 사용하는 방법
빈 등록과 의존관계 주입이 나뉘어져 있는 경우임
값 주입해주면 생성자 주입은 필요없음

@Component
class OrderServiceImpl: OrderService{

	lateinit var memberRepository: MemberRepository
    lateinit var discountPolicy: DiscountPolicy
    
    @Autowired
    fun setMemberRepository(memberRepository: MemberRepository){
    	this.memberRepisotry = memberRepository
    }
	
    @Autowired
    fun setDiscountPolicy(discountPolicy: DiscountPolicy){
    	this.discountPolicy = discountPolicy
    }

}

필드 주입

: 필드에 바로 주입하는 방법이다.

[특징]

코드가 간결하다
외부에서 변경이 불가능해 테스트하기 힘들다는 단점이 있다
DI 프레임워크가 없으면 아무것도 할 수 없다

쓰지 말자.

@Component
class OrderServiceImpl: OrderService{
	
    @Autowired
	lateinit var memberRepository: MemberRepository
    @Autowired
    lateinit var discountPolicy: DiscountPolicy
    
    }

}

일반 메서드 주입

: 일반 메서드를 통해서 주입 받을 수 있다.

[특징]

한번에 여러 필드를 주입받을 수 있다

일반적으로 잘 사용하지 않는다.

의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야 동작한다. 스프링 빈이 아닌 클래스에서 Autowired 코드를 적용해도 아무 기능도 동작하지 않는다.

옵션 처리

주입할 스프링 빈이 없어도 동작해야 할 때가 있다

하지만 @Autowired만 사용하면 required 옵션 default 값이 true이기 때문에 자동 주입 대상이 없으면 오류가 발생할 수 있다.

[해결방법]

Autowired(required = false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안됨

org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 null이 입력된다

Optional<> : 자동 주입할 대상이 없으면 Optional.empty가 입력된다

Optional은 값이 null일수도 있고 아닐수도 있다는 상태를 감싼 것이다.

@Nullable, Optional은 스프링 전반에 걸쳐서 지원된다.

왜 생성자 주입을 선택해야 하는가?

최근에는 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 권장한다.

[이유]

1. 불변

대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료까지 변경할 일이 없다.
수정자 주입을 사용하면 setter 메서드들을 public으로 열어두어야 한다.

2. 누락

: 프레임워크 없이 순수 자바 코드 단위 테스트하는 경우 생성자 주입을 사용하면 필수 값들이 안들어가면 컴파일 오류가 뜨가 때문에 미리 버그를 잡을 수 있다.(@Autowired가 동작하지 않기 때문에)

3. final 키워드를 넣을 수 있음

생성자 주입을 사용하면 필드에 final 키워드를 넣을 수 있다.

kotlin에서도 val을 사용할 수 있다.

[결론]

생성자 주입은 프레임워크에 의존하지 않고 순수한 자바 언어의 특징을 잘 살리는 방법이다.
기본으로 생성자 주입을 사용하고 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 사용할 수 있다.
항상 생성자 주입을 사용하고 옵션이 필요하면 수정자 주입으로, 필드 주입은 사용하지 않는 것이 좋다.

조회 빈이 2개 이상인 경우

@Autowired는 타입으로 빈을 조회한다.

따라서 선택된 빈이 2개 이상일 때 문제가 발생한다.

이때의 해결방법을 알아보자

@Autowired 필드 명 매칭

@Autowired는 타입 매칭을 시도하고 이때 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭한다.

@Qualifier -> @Qualifier 끼리 매칭 -> 빈 이름 매칭

@Qualifier는 추가 구분자를 붙여주는 방법이다.

이것은 빈 이름을 변경하는 것은 아니다.

등록 시 Qualifier 애노테이션 붙이고 생성자 주입에서나 수정자 주입에서 필드 앞에 Qualifier 애노테이션으로 지정하면 된다.

@Component
@Qualifier("mainDiscountPolicy")
class RateDiscountPolicy: DiscountPolicy{...}

@Autowired
constructor(memberRepository: MemberRepository, 
			@Qualifier("mainDiscountPolicy") discountPolicy: DiscountPolicy){
            
	this.memberRepository = memberRepository
    this.discountPolicy = discountPolicy
}

@Qualifier로 주입할 때 해당 Qualifier를 못찾으면 위의 mainDiscountPolicy 처럼 Qualifier안의 문자열과 같은이름의 스프링 빈을 추가로 찾는다.

하지만 Qualifier용도로만 사용하는 게 명확하고 좋다.

@Primary 사용

이것도 편하고 자주 사용하는 방법이다.

@Autowired시에 여러 빈이 매칭이 되면 @Primary 가진 빈이 우선권을 가진다.

메인 DB 커넥션을 획득하는 스프링 빈은 Primary를 적용해서 조회하는 것에 Qualifier지정 없이 편하게 조회하고,
서브 DB 커넥션 빈을 획득할 때는 Qualifier 지정해서 명시적으로 획득하면 코드를 깔끔하게 유지할 수 있다.

Primary와 Qualifier가 만나면 Qualifier 가 우선권을 갖는다
Qualifier이 더 세세한 설정이기 때문

애노테이션 직접 만들기

@Qualifier("xxx") 이렇게 적으면 컴파일 시 문자열로 타입 체크가 안되기 때문에 실수를 모르고 넘어갈 수 있다.

이때 @xxx 과 같은 애노테이션을 만들어서 문제를 해결할 수 있다.

package soyang.hellocore.annotation

import org.springframework.beans.factory.annotation.Qualifier
import java.lang.annotation.*
import java.lang.annotation.Retention
import java.lang.annotation.Target

@Target(ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
@Qualifier("mainDiscountPolicy")
annotation class MainDiscountPolicy()

package soyang.hellocore.discount

import org.springframework.stereotype.Component
import soyang.hellocore.annotation.MainDiscountPolicy
import soyang.hellocore.member.Grade
import soyang.hellocore.member.Member

@Component
@MainDiscountPolicy
class RateDiscountPolicy: DiscountPolicy {...}

@Component
class OrderServiceImpl: OrderService {

    val memberRepository: MemberRepository
    val discountPolicy: DiscountPolicy

    @Autowired
    constructor(memberRepository: MemberRepository,
                @MainDiscountPolicy discountPolicy: DiscountPolicy){
        this.memberRepository = memberRepository
        this.discountPolicy = discountPolicy
    }

	...
}

애노테이션에는 상속이라는 개념이 없다.
이렇게 여러 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능이다.
Autowired도 재정의 가능하지만 뚜렷한 기능을 무분별하게 재정의하는 것은 유지보수에 혼란을 줄 뿐이다.

조회한 빈이 모두 필요할 때, List, Map

의도적으로 해당 타입의 스프링 빈이 모두 필요한 경우도 있다.

스프링을 사용하면 소위 말하는 전략 패턴을 간단하게 구현할 수 있다.(선택 할 수 있도록)

서비스가 모든 Policy를 다 주입받고 어떤 메서드로 string이 내려오면 map에서 string으로 Policy 찾아서 해당 로직을 호출하면 된다.

HashMap<String, 빈 타입>으로 빈을 모두 저장한 다음 입력된 spring으로 검색해서 해당 빈을 사용해서 로직 수행하면 된다.

실무에서는 HashMap 대신 ConcurrentHashMap을 써야 Thread-safe 하게 동작할 수 있다.

자동, 수동의 올바른 실무 운영 기준

편리한 자동 기능을 기본으로 하자

: 스프링이 나오고 시간이 많이 지나서 Component 뿐만 아니라 Controller, Service, Repository 처럼 계층에 맞추어 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한다.

자동 빈 등록을 해도 OCP, DIP 지킬 수 있다.

기술 지원 로직의 경우에는 수동 등록하자

앱은 크게 업무 로직과 기술 지원 로직으로 나뉜다.

업무 로직 빈 : 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리 등이 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가하거나 변경된다.

기술 지원 빈 : 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. DB 연결이나 공통 로그 처리처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들이다.

업무로직은 숫자도 많고 유사한 패턴이 있으므로 자동 기능을 사용하고

기술지원 로직은 수는 적지만 애플리케이션 전반에 걸쳐서 광범위하게 영향을 미치고 적용이 잘 되고 있는지 여부를 파악하기 어려운 경우가 많으므로 수동 빈 등록을 해서 명확하게 드러내는 것이 좋다.

[출처]

스프링 핵심 원리 - 기본편

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

스프링 핵심 원리 - 기본편 - 인프런 | 강의

스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다., - 강의 소개 | 인프런...

www.inflearn.com

[Spring][Kotlin]컴포넌트 스캔

haileykim1 — Thu, 19 May 2022 00:44:03 +0900

컴포넌트 스캔과 의존관계 자동 주입

스프링은 설정 정보 없이도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다.

+ 의존관계 자동으로 주입하는 @Autowired 기능도 제공한다.

컴포넌트 스캔

@ComponentScan을 설정정보에 붙여주면 된다.

컴포넌트 스캔은 @Component 애노테이션이 붙은 클래스를 스캔해서 스프링 빈으로 등록한다.

Autowired 의존관계 자동 주입

이전에는 설정정보 클래스에서 @Bean으로 직접 설정 정보를 작성했고 의존관계도 명시했다.

하지만 컴포넌트 스캔을 사용하면 이런 설정 정보 자체가 없기 때문에 의존관계 주입도 @Autowired를 통해서 해주어야한다.

@Autowired를 사용하면 생성자에서 여러 의존관계도 한번에 주입받을 수 있다.

@Autowired 테스트 시 싱글톤 빈의 인스턴스 인식한 로그와 Autowired한 내용도 나오는데, 빈 이름 규칙은 다음과 같다.

스프링 빈의 이름은 클래스 명에서 맨 앞글자를 소문자로 바꾼 것
빈 이름 직접 지정 : @Component("이름")

생성자에 파라미터가 많아도 @Component 붙은 클랫 다 찾아서 자동으로 주입한다.

탐색 위치와 기본 스캔 대상

탐색 할 패키지의 시작 위치 지정

모든 클래스를 다 컴포넌트 스캔하면 시간이 오래 걸린다.

따라서 꼭 필요한 위치에서부터 탐색하도록 위치를 지정할 수 있다.

basePackages : 탐색할 패키지의 시작 위치를 지정한다. 이 패키지를 포함해서 하위 패키지를 모두 탐색한다.

basePackageClasses : 지정한 클래스의 패키지를 탐색 시작 위치로 지정한다.

컴포넌트 스캔 기본 대상

컴포넌트 스캔은 @Component뿐만 아니라 다음 내용도 추가로 대상에 포함된다.

@Component : 컴포넌트 스캔에 사용
@Controller : 스프링 MVC 컨트롤러에서 사용
@Service : 스프링 비즈니스 로직에서 사용
@Repository : 스프링 데이터 접근 계층에서 사용
@Configuration : 스프링 설정 정보에서 사용

해당 애노테이션으로 가보면 안에 @Component 붙어있다.
하지만 사실 Annotation에는 상속관계라는게 없다.
애노테이션이 특정 애노테이션을 들고 있다는 것은 자바 언어가 인식하는 것은 아니고 스프링이 지원하는 기능이다.

컴포넌트 스캔의 용도 뿐만 아니라 다음 애노테이션이 있으면 스프링은 부가 기능을 수행한다.

@Controller : 스프링 MVC 컨트롤러로 인식
@Repository : 스프링 데이터 접근 계층으로 인식, 데이터 계층의 예외를 스프링 예외로 변환해줌
@Configuration : 스프링 설정 정보로 안식하고 스프링 빈이 싱글톤을 유지하도록 추가 처리함
@Service : 특변한 처리하지 않지만 개발자들이 핵심 비즈니스 로직 계측 인식하는 데 도움을 줌

필터

includeFilters : 컴포넌트 스캔 대상 추가 지정

excludeFilters : 컴포넌트 스캔에서 제외할 대상 지정

자체 애노테이션 만들어서 적용 대상 지정할 수 있다.

FilterType 옵션

ANNOTATION : 디폴트. 애노테이션을 인식해서 동작
ex) org.example.xxAnnotation
ASSIGNABLE_TYPE : 지정한 타입과 자식 타입을 인색해서 동작한다.
ex) org.example.xxClass
REGEX : 정규 표현식
ex)org\.example\.Default.*

등...

(잘 사용하는 일이 없다)

중복 등록과 충돌

Q. 컴포넌트 스캔에서 같은 빈 이름으로 등록하면 어떻게 될까?

자동 빈 등록 vs 자동 빈 등록
자동 빈 등록 vs 수동 빈 등록

자동 빈 등록 vs 자동 빈 등록

스프링에 의해 ConflictBeanDefinitionException 예외가 발생한다.

자동 빈 등록 vs 수동 빈 등록

수동 빈 등록이 우선권을 가진다.

수동빈이 자동빈을 오버라이딩 해버리고 스프링이 오버라이딩 했다고 로그를 남겼다.

이것으로 인해 여러 설정들이 꼬려 버그가 많이 만들어졌다.
그래서 최근 스프링부트에서는 수동 빈 등록과 자동 빈 등록이 충돌나면 오류가 발생하도록 기본 값을 바꾸었다.

[출처]

스프링 핵심 원리 - 기본편

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

스프링 핵심 원리 - 기본편 - 인프런 | 강의

스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다., - 강의 소개 | 인프런...

www.inflearn.com

[Spring][Kotlin] 싱글톤 컨테이너

haileykim1 — Wed, 18 May 2022 19:19:10 +0900

스프링은 기업용 온라인 서비스 기술을 지원하기 위해 탄생했다.
그리고 대부분 스프링 애플리케이션은 웹 애플리케이션이다.
웹앱은 보통 여러 고객이 동시에 요청한다.

Problem] Request 마다 객체 생성하면 메모리 낭비가 매우 심하다.
Sol) 해당 객체를 1개만 생성하고 공유하도록 하면 된다.
(사실 요즘 GC가 좋아서 초당 100최 정도는 괜찮지만 효율적이면 좋으니까)

싱글톤 패턴

: 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다.

-> 객체 인스턴스가 2개 이상 생성 못하도록 막야야 한다.

싱글톤 구현 방법은 많다.
그 중 하나의 방법은 private 생성자를 사용해서 생성자를 사용하지 못하도록 막는 것이다.

Kotlin에서는 object 키워드를 붙이면 싱글톤 클래스 생성이 가능하다.
※단, 생성자에 파라미터 넣지 않는 클래스에서만 사용이 가능하다.
생성자 통해 파라미터 전달받는 싱글톤 클래스는 companion object를 사용하면 된다.

싱글톤 패턴의 문제점

구현 코드 자체가 많이 들어간다.
클라이언트가 구체 클래스에 의존한다.(내부적으로 객체 반환 함수를 만든다면) -> DIP위반, OCP위반 가능성↑
유연성이 떨어져서 테스트 하기가 어렵다.
내부 속성을 변경하고 초기화 하기 어렵다.
private생성자로 자식 클래스를 만들기 어렵다.
안티패턴으로 불리기도 한다.

-> 스프링 컨테이너는 default로 객체를 싱글톤으로 만들어서 관리해준다(성능 굿굿)

싱글톤 컨테이너

: 싱글톤 패턴의 문제점을 해결하면서 객체 인스턴스를 싱글톤으로 관리해준다.

(객체를 미리 생성해서 관리해주기 때문에 지저분한 코드가 없고 DIP, OCP, 테스트 모두 유연하게 가능하다.)

실제로 조회할 때 마다 같은 객체를 반환한다.

싱글톤 방식의 주의점

: 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 stateful 하게 설계하면 안된다.

무상태 stateless

특정 클라이언트에 의존적인 필드가 있으면 안된다.

특정 클라이언트가 값 변경할 수 있는 필드가 있으면 안된다

가급적 읽기만 가능하게 해야한다.

필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 이용해야한다.

※스프링 빈의 필드에 공유 값 설정 시 큰 장애가 발생한다.

=> 스프링은 항상 무상태로 설계하자!

@Configuration과 싱글톤

@Configuration은 싱글톤을 위해 존재한다.

@Bean
fun memberService() = MemberServiceImpl(memberRepository())

@Bean
fun orderService() = OrderServiceImpl(memberRepository(), discountPolicy())

@Bean
fun memberRepository() = MemoryMemberRepository()

위 예제코드의 경우 memberService와 orderService 빈을 만드는 코드를 보면 memberRepository()를 호출한다.

또 memberRepository 빈을 만드는 코드도 실행된다.

그런데 memberRepository는 MemoryMemberRepository 생성자를 호출하며 3개의 객체가 생성되면서 싱글톤이 깨지는 것 처럼 보인다.

하지만 memberRepository는 빈 등록 시 1번만 호출된다. -> 싱글톤 보장

@Configuration과 바이트 코드 조작

위의 Kotlin코드 자체만 보면 3번 호출되어야하는게 맞지만,

스프링은 이것이 되게 하기 위해 바이트코드를 조작하는 라이브러리를 사용한다.

@Test
@DisplayName("CGLIB 확인하기")
fun confiruationDeep(){
    val bean = ac.getBean(AppConfig::class.java)
    println("bean = ${bean::class.java}")
}

예제 코드 실행 시 나온 결과

클래스 정보를 출력하면 클래스 이름인 AppConfig가 아닌 AppConfig&&EnhancerBySpringCGLIB$$~~~가 출력된다.

CGLIB

이것은 사용자가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트 조작 라이브러리를 사용해서 해당 클래스를 상속받은 임의의 다른 클래스를 만들고 그 클리스를 스프링 빈으로 등록한 것이다.

-> 물론 해당 클래스의 자식 타입이므로 스프링 빈의 해당 클래스 타입으로 조회가 가능하다.

만약 @Configuration를 안붙이면 CGLIB 안쓰기 때문에 순수한 인스턴스가 조회되고 싱글톤이 깨진다.

[출처]

스프링 핵심 원리 - 기본편

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

스프링 핵심 원리 - 기본편 - 인프런 | 강의

스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다., - 강의 소개 | 인프런...

www.inflearn.com

[Spring][Kotlin] 스프링 컨테이너

haileykim1 — Thu, 12 May 2022 16:37:37 +0900

ApplicationContext를 스프링 컨테이너라고 한다.

ApplicationContext 는 인터페이스인데 XML기반, 애노테이션 기반의 자바 설정 클래스로 하는 구현체를 선택할 수 있다.

애노테이션 기반의 자바 설정 클래스를 기반으로 하는 스프링 컨테이너는 아래와 같이 만들 수 있다.

//스프링 컨테이너 생성
val applicationContext = AnnotationConfigApplicationContext(AppConfig::class.java)

AnnotationConfigApplicationContext -> 이 클래스는 ApplicationContext 인터페이스의 구현체이다.

스프링컨테이너를 부를 때 Bean Factory, ApplicationContext로 구분하지만 일반적으로는 ApplicationContext를 스프링 컨테이너라고 한다.

스프링 컨테이너

: 사용 할 객체들 담고 있는 것.

스프링 컨테이너의 생성 과정

1. 스프링 컨테이너 생성

여기서는 AppConfig.class를 구성 정보를 지정하였다.

2. 스프링 빈 등록

스프링 컨테이너는 설정 클래스 정보를 사용해서 스프링 빈을 등록한다. @Bean Annotation을 붙여주면 된다.

3. 스프링 빈 의존관계 주입

스프링 컨테이너는 설정 정보를 참고해서 DI 한다.

빈 이름은 겹치지 않게 설정해야 한다.
겹치면 다른 빈을 무시하거나 기존 빈을 덮어버리거나 설정에 따른 오류가 발생한다.

컨테이너에 등록된 빈 조회

컨테이너에 등록된 모든 빈 조회

아래는 구성 정보를 담고 있는 AppConfig class이다.

package soyang.hellocore

import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import soyang.hellocore.discount.DiscountPolicy
import soyang.hellocore.discount.RateDiscountPolicy
import soyang.hellocore.member.MemberRepository
import soyang.hellocore.member.MemberService
import soyang.hellocore.member.MemberServiceImpl
import soyang.hellocore.member.MemoryMemberRepository
import soyang.hellocore.order.OrderService
import soyang.hellocore.order.OrderServiceImpl

@Configuration
class AppConfig {


    @Bean
    fun memberService(): MemberService = MemberServiceImpl(memberRepository())

    @Bean
    fun orderService(): OrderService = OrderServiceImpl(memberRepository(), discountPolicy())

    @Bean
    fun memberRepository(): MemberRepository = MemoryMemberRepository()

    @Bean
    fun discountPolicy(): DiscountPolicy = RateDiscountPolicy()

}

모든 Bean을 출력하는 테스트 코드를 작성했다.

package soyang.hellocore.beanfind

import org.junit.jupiter.api.DisplayName
import org.junit.jupiter.api.Test
import org.springframework.context.annotation.AnnotationConfigApplicationContext
import soyang.hellocore.AppConfig

class ApplicationContextInfoTest {

    val ac = AnnotationConfigApplicationContext(AppConfig::class.java)

    @Test
    @DisplayName("모든 빈 출력하기")
    fun findAllBean(){
        val beanDefinitionNames = ac.beanDefinitionNames
        beanDefinitionNames.forEach{
            val bean = ac.getBean(it)
            println("name=$it obejct=$bean")
        }
    }

}

Test 실행 결과

그 중 이 부분이 모든 Bean 조회 결과이다.

AppConfig도 스프링 빈도 등록된다!!

직접 등록한 memberService, orderService, memberReository, discountPolicy 외에도 Bean들이 있다.

그 위에 출력되는 빈들은 스프링이 내부적으로 사용하는 빈들이다.

애플리케이션 빈 출력하기

이때 Role을 사용하여 사용자 정의 빈을 따로 조회할 수 있다.

ROLE_APPLICATION : 직접 등록한 애플리케이션 빈
ROLE_INFRASTRUCTURE : 스프링이 내부에서 사용하는 빈

@Test
@DisplayName("애플리케이션 빈 출력하기")
fun findApplicationBean(){
    val beanDefinitionNames = ac.beanDefinitionNames
    beanDefinitionNames.forEach{
        val beanDefinition = ac.getBeanDefinition(it)
        if(beanDefinition.role == BeanDefinition.ROLE_APPLICATION){
            val bean = ac.getBean(it)
            println("name=$it obejct=$bean")
        }
    }
}

Test를 돌려보면 내가 등록한 빈들만 출력된다.

빈 조회 방법

val bean1 = ac.getBean(빈 이름, 타입)
//또는
val bean2 = ac.getBean(타입)

메서드에서 반환하는 대상이 없으면 suchNoBeanDefinitionException이 발생한다.

빈 조회 시 구체 타입으로 조회가 가능하지만 유연성이 떨어지므로 좋지 않다.

동일한 타입이 둘 이상인 경우

//해당 타입 모든 빈 조회. Map 반환
val map = ac.getBeansOfType(타입)

Configuration 클래스를 inner class로 만들면 UnsatifiedDependencyException이 발생하였다.

이유를 찾아봤는데,
innerclass는 outerclass에 종속되어 있다.
따라서 outerclass가 생성되어야 사용이 가능하다.
근데 외부 클래스 객체가 생성되기도 전에 스프링 컨테이너에서 innerclass를 찾아오려고 한다.
그럼 그런 클래스가 없다고 오류가 발생하는 것이다.
=> Sol) static(companion object)로 생성해주면 외부 클래스 객체 생성 유무와 별개로 생성되어서 독립적으로 사용이 가능하다.

상속관계일 경우 조회

: 부모타입 조회 시 자식타입이 함께 조회된다. (줄줄이 다 끌려나온다.)

그래서 Object 타입으로 조회 시 모든 스프링 빈이 조회된다.

BeanFactory와 ApplicationContext

BeanFactory

스프링 컨테이너 최상위 인터페이스이다.
스프링 빈을 관리하고 조회하는 역할을 담당한다.
ex) getBean()

ApplicationContext

: BeanFactory의 모든 개능을 상속받아 제공한다.

그 외 제공하는 부가기능( + Bean 관리 기능)

메시지 소스 이용한 국제화 기능 : 언어별 파일 분리
환경변수 : 각 환경별로 어떤 DB연결해야할지 등 환경변수와 관련된 정보 처리
애플리케이션 이벤트 : 이벤트 발행, 구독 모델 편리하게 지원
편이한 리소스 조회 : 파일, 클래스 패스, 외부 리소스 추상화 등 편리하게 조회

스프링 컨테이너는 다양한 설정 정보 받아들일 수 있게 유연하게 설계되어 있다.

XML로 설정

GenericXmlApplicationContext() 사용한다.

장점 : 컴파일 없이 빈 설정정보를 변경 기능하다.

스프링 빈 설정 메타정보 - BeanDefinition

Spring이 다양한 설정 형식을 지원할 수 있는 건 BeanDefinition이라는 추상화가 있기 때문이다.

(역할과 구현을 분리하였다.)

이 BeanDefinition이 빈 설정 메타정보이다.

@Bean 하나 당 메타정보가 하나씩 생성된다.

스프링 컨테이너는 이 메타정보를 기반으로 스프링 빈을 생성한다.

(스프링 컨테이너는 추상화에만 의존하는 것이다.)

ApplicationContext의 Reader가 설정정보(AppConfig.class)를 쭉 읽은 다음 빈 메타정보를 생성한다(BeanDefinition)

필요하다면 ApplicationContext를 상속받은 임의의 형식을 만들어도 된다.

스프링 빈 등록 방법에는

1. 직접 등록 방법

2. Factory Bean 통해서 쓰는 법

이 있다.

2번은 지금까지 한 방법이고,

BeanDefinition에서 팩토리빈, 팩토리 메서드 확인이 가능하다.

[출처]

스프링 핵심 원리 - 기본편

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

스프링 핵심 원리 - 기본편 - 인프런 | 강의

스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다., - 강의 소개 | 인프런...

www.inflearn.com

[Spring][Kotlin] 제어의 역전(Ioc)과 의존관계 주입(DI)

haileykim1 — Wed, 13 Apr 2022 01:08:20 +0900

제어의 역전 IoC (Inversion of Control)

: 구현 객체가 제어 흐름을 스스로 조종하지 않고 외부에서 관리하는 것을 말한다.

앞 포스팅에서의 코드에서

class MemberServiceImpl: MemberService(){

	val memberRepository = MemoryMemberRepository()
    
	//생략
}

위의 코드는 MemberServiceImpl 객체가 스스로 필요한 서버 구현 객체를 생성하고 연결하고 실행한다.

즉 구현 객체가 프로그램의 제어 흐름을 조종한다.

class AppConfig{
	
    fun memberRepository() = MemoryMemberRepository()
    
	fun memberService() = MemberServiceImpl(memberRepository())
    
    //생략
    
}

하지만 AppConfig가 등장하고는 제어 흐름의 권한은 AppConfig에게 있다.

객체들은 자신의 로직을 실행할 뿐이다.

이렇게 제어의 흐름이 외부에서 관리되는 것을 IoC 라고 한다.

c.f] 프레임워크 vs 라이브러리
내가 작성한 코드를 제어하고 대신 실행한다면 프레임워크. ex) JUnit
내가 작성한 코드가 직접 제어흐름을 담당한다면 그것은 라이브러리.

여기서 JUnit을 예로 들면 프레임워크는 본인만의 라이프 사이클이 있다.
BeforeEach 먼저 실행하고 Test 실행, AfterEach 실행 이런 흐름.
그 lifecycle 속에서 내 코드는 콜백 형태로 호출되는것이다.
즉 프레임워크 안에서 적절한 타이밍에 내 코드가 호출된다.

의존관계 주입 DI (Dependency Injection)

클라이언트는 어떤 구현 객체가 사용될 지 모른 채 인터페이스에 의존한다.

이때 실행 시점(런타임)에 외부에서 실제 구현 객체를 클라이언트에 전달해서 실제 의존관계가 연결되는 것을 의존관계 주입이라고 한다.

[정적인 클래스 의존관계]
: import 코드만 보고도 파악 가능한 의존관계
앱을 실행하지 않고도 분석 가능하다.
하지만 이것만으론 실제 어떤 객체가 주입될 지 알 수 없다.

[동적인 객체 의존관계]
: 애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결관 의존관계

DI(의존관계 주입)을 사용하면 정적인 클래스 의존관계를 변경하지 않고 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

이렇게 IoC, DI 해주는 컨테이너를

IoC 컨테이너 = DI 컨테이너 = 어셈블러 = 오브젝트 팩토리

라고 한다.

의존관계 주입에 초점 맞추어 최근에는 주로 DI 컨테이너라고 한다고 한다.

DI 컨테이너 ex) AppConfig, Spring..etc

[출처]

스프링 핵심 원리 - 기본편

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

스프링 핵심 원리 - 기본편 - 인프런 | 강의

스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다., - 강의 소개 | 인프런...