본문 바로가기

Method Injection 동일한 scope 의 bean 에 의존성을 가질 때, 일반적으로 bean 의 속성에 의존성을 추가하여 처리한다. 예를 들어 singleton bean 이 prototype bean 을 의존한다면, 컨테이너는 singleton bean 을 단 한번 생성하므로 필요할 때마다 prototype bean 을 제공할 수 없다. 아래는 ApplicationContextAware 를 구현하여 singleton bean 에서 prototype bean 의 새 인스턴스를 요청하는 예제이다. package fiona.apple; // Spring-API importsimport org.springframework.beans.BeansException;import org.springframework.context.Appli..
Bean scopes 컨테이너로부터 bean 을 호출하였을 때, 요청 수 만큼의 bean 인스턴스를 반환할 것인지, 하나의 bean 인스턴스로 계속해서 반환할 것인지 등을 요소의 scope 속성을 설정하거나, 컴포넌트에 @RequestScope 처럼 @*Scope 어노테이션을 사용하여 제어할 수 있다. Spring Framework 는 7가지의 scope 를 지원하며 사용자 정의 scope 를 만들 수도 있다. singleton scope scope 를 지정하지 않은 bean 은 singleton scope 이다(default). Spring IoC 컨테이너는 해당 bean 정의의 객체 인스턴스를 정확히 하나 생성한다. 이 인스턴스는 singleton bean 의 캐시에 저장되고, 그 이후의 모든 요청과 해당 이름의 Bean..
Dependencies 특정 객체가 속성에 다른 객체를 필요로 하여 생성자나 setter 방식으로 주입시켜 함께 작동할 때, 다른 객체를 의존성(dependency) 이라 하고 이를 주입시키는 행위를 의존성 주입(DI: Dependency Injection) 이라고 한다. Spring 에서는 컨테이너가 bean 을 생성할 때 의존성을 주입하게 된다. 의존성 주입의 원리를 사용하면 객체는 의존성의 위치나 클래스와 완벽하게 분리될 수 있다. 인터페이스 또는 추상 클래스에 의존성이 있으면, 단위 테스트에서 스텁(stub) 이나 모의(mock) 구현을 쉽게 사용할 수도 있다. ApplicationContext 는 자신이 관리하는 bean 에 대해 생성자(Constructor) 및 세터(Setter) 기반의 의존성 주입을 지원한다. 필..
Bean Spring IoC 컨테이너가 관리하는 모든 객체를 bean 이라고 한다. XML 메타데이터에 요소를 사용하거나, @Bean 어노테이션을 사용하여 bean 을 정의할 수 있다. bean 정의에는 패키지를 포함한 클래스 이름, scope, 라이프사이클 콜백, 다른 bean 의 참조(의존성), 해당 bean 의 추가 설정 등이 포함되어야 한다. 이 메타데이터들은 실제로 컨테이너 내부에서 BeanDefinition 객체를 통해 bean 으로 정의된다. bean 의 속성 id / name 속성 컨테이너 내의 bean 은 중복된 이름을 가질 수 없으며, 유일해야 한다. 요소의 id 나 name 속성을 사용하여 bean 의 식별자를 지정할 수 있으며, 주로 camel-case ('myBean', 'fooServic..
IoC 컨테이너 대부분의 어플리케이션은 유지보수가 필요하다. 불가피하게 수정을 하는 일이 발생하기도 하고, 추가 기능이 필요하기도 하다. 이 때 조금더 빠르고 간편하게 업데이트를 하기 위해서는 클래스 객체가 서로 분리되어 있어야 한다. 쉽게 말해 하나의 클래스를 수정한다고 해서 다른 클래스도 수정해야 하고, 또 다른 클래스까지 수정하는 일이 발생하지 않도록 개발해야 한다. Spring 에서 이러한 객체간의 결합도를 완화시켜주는 일을 하는 것이 바로 IoC 컨테이너(Inversion of Control) 이다. IoC 컨테이너는 객체와 객체 간의 의존성을 정의해 놓은 메타데이터를 기반으로 작동하기 때문에, 유지보수 시에는 해당 소스와 메타데이터만 수정하는 것으로 많은 노력을 줄여준다. 이 컨테이너를 IoC, 즉 “제어의 ..
Logback Configuration Logback 구성 파일을 사용하면 코드를 다시 컴파일 할 필요없이 logging 동작을 재정의 할 수도 있다.구성 파일에 로그를 어떤 형태로 어디에 남길 것인지에 대한 계획도 명시할 수 있으며, 프로그래밍 방식이나 XML, Groovy 형식으로도 작성할 수 있다.Logback 웹사이트에서 기존 log4j 사용자를 위한 PropertiesTranslator 도 제공한다. (log4j.properties -> logback.xml) Logback 의 구성 파일 검색 순서 classpath 에서 logback-test.xml 파일 검색.없으면 logback.groovy 파일 검색.없으면 logback.xml 파일 검색.없으면 BasicConfigurator 를 사용하여 logback 을 가장 기본적으로 구성..
Logback Architecture Logback 은 Logger, Appender, Layout 의 세 가지 기본 클래스를 기반으로 한다.이를 사용하여 개발자는 메시지 유형 및 수준에 따라 메시지를 기록하고 런타임에 이러한 메시지의 형식과 보고 위치를 설정할 수 있다.Logger 클래스는 logback-classic 모듈에 속하고, Appender 및 Layout 인터페이스는 logback-core 에 속하기 때문에, logback-core 에는 logger 의 개념이 없다. Logger Class Logger 의 레벨인 TRACE, DEBUG, INFO, WARN, ERROR 는 ch.qos.logback.classic.Level 클래스에 정의된다.Logger 레벨을 지정하지 않으면 상위 클래스에서 상속받게 되고, default 레벨은..
Logback Intro log4j 를 만든 Ceki Gülcü 는 log4j 를 포함한 다른 logging 시스템들 보다 더 가볍고 빠르게 동작하는 Logback 을 개발하였다.log4j 와 logback 은 개념적으로 매우 유사하고, log4j 를 사용했던 사용자라면 logback 역시 쉽게 다가갈 수 있다.System.out.println 와 비교하자면 빠르고, 레벨, 환경 등에 따라 출력 여부를 표시할 수 있다는 점? Logback 모듈 Logback 은 logback-core, logback-classic, logback-access 세 가지 모듈로 나뉜다. logback-classic 은 log4j 의 향상된 버전에 해당하며, SLF4J API를 기본적으로 구현하여 log4j 이나 JUL 과 같은 다른 로깅 시스템과 ..