스프링의 자바 기반 configuration 기능은 configuration의 복잡성을 줄일 수 있는 어노테이션들을 구성하게 한다.
@Import 어노테이션의 사용
<Import/> 요소가 스프링 XML 파일에서 configuration 모듈화하는데 도움을 주고, @Import 어노테이션은 @Bean 정의를 다른 configuration 클래스로부터 부른다.
@Configuration
public class ConfigA {
@Bean
public A a() {
return new A();
}
}
@Configuration
@Import(ConfigA.class)
public class ConfigB {
@Bean
public B b() {
return new B();
}
}
이제, ConfigA.class와 ConfigB.class 둘다 지정하지 않아도 컨텍스트를 초기화할때 오직 ConfigB 명시적으로 공제공한다.
말을 어렵게 했는데, 결국은 ConfigB 클래스가 ConfigA를 import하기 때문에 ConfigB만 불러온 것이 명시적이란 이야기.
public static void main(String[] args) {
ApplicationContext ctx = new AnnotationConfigApplicationContext(ConfigB.class);
// now both beans A and B will be available...
A a = ctx.getBean(A.class);
B b = ctx.getBean(B.class);
}
이러한 접근은 @Configuration 이 동작하는 동안 잠재적으로 많은 클래스를 기억하도록 요구하는거 보다 하나의 클래스만 처리해야해서 컨테이너 인스턴스화를 단순화한다.
스프링 4.2에서 @Import는 또한 보통 컴포넌트 클래스 참조를하는 것이 AnnotationConfigApplicationContext.register 메소드와 유사하다. 이는 특히 컴포넌트 스캐닝을 피하려고 한다면 유용하다. 모든 컴포넌드들을 명시적으로 정의하기 위해 엔트리 포인트들 로서 적은 configuration 클래스들을 사용하는 것으로.
하나의 클래스만 명시적으로 적는 것으로 단순화 & 기능별로 config 클래스를 나눠서 스캐닝을 원하지 않는 패키지들을 분리할 수 있다.
임포트된 @Bean 정의에 의존성 주입
아래 예제는 간단하게 동작한다. 대부분 실용성있는 시나리오에서는 빈들은 또 하나의 cross configuration 클래스들의 의존성을 가진다. XML을 사용할때 컴파일러가 연루되지 않기 때문에 이건 이슈가 안되고, ref="someBean"을 선언할 수 있고, 컨테이너가 초기화되는 동안 스프링이 일하는 것을 믿을 수 있다. @Configuration클래스를사용하면, 자바 컴파일러가 configuration 모델에 제약을 주기 때문에 다른 빈들로 참조하는 것이 자바 신택스에 유효해야만 한다.
XML로 선언한 것과 자바 코드로 선언한 것들은 서로 참조할 수 있고, 자바 코드는 유효해야(빌드가 되어야하니까) 사용가능하다는 조건이 있지만 XML은 그렇지 않다는 이야기.
@Configuration
public class ServiceConfig {
@Bean
public TransferService transferService(AccountRepository accountRepository) {
return new TransferServiceImpl(accountRepository);
}
}
@Configuration
public class RepositoryConfig {
@Bean
public AccountRepository accountRepository(DataSource dataSource) {
return new JdbcAccountRepository(dataSource);
}
}
@Configuration
@Import({ServiceConfig.class, RepositoryConfig.class})
public class SystemTestConfig {
@Bean
public DataSource dataSource() {
// return new DataSource
}
}
public static void main(String[] args) {
ApplicationContext ctx = new AnnotationConfigApplicationContext(SystemTestConfig.class);
// everything wires up across configuration classes...
TransferService transferService = ctx.getBean(TransferService.class);
transferService.transfer(100.00, "A123", "C456");
}
이는 같은 결과인 또다른 방법이다. @Configuration 클래스들은 궁극적으로 컨테이너에서 오직 하나의 빈이다.: 이는 @Autowired와 @Value 주입의 이점이 될 수 있고 다른 기능들은 다른 빈들과 같다.
가장 간단한 방법으로 주입하는 의존성을 확인하자. @Configuration 클래스들은 컨텍스트의 초기화 동안 꽤 빨리 동작하고, 이 방법은 기대하지 않게 빨리 초기화하는 걸로 이끌지도 모른다. 가능하다 파라미터 기반 주입을 하자.
또한, 특히 @Bean 을 통해 BeanPostProcessor와 BeanFactoryPostProcessor 정의하는 것에 주의해야한다. 이것들은 static @Bean메소드에 보통 선언되어야 하고 configuration클래스를 컨테이닝하는 초기화를 트리거링 하면 안된다. 그렇지 않으면, @Autowired와 @Value는 configuration 클래스에서 스스로 동작하지 않는다. 빈인스턴스가 너무 빨리 동작하기 때문에.
아래 예제는 하나의 빈이 다른 빈에 Autowired될 수 있는 방법이다.
@Configuration
public class ServiceConfig {
@Autowired
private AccountRepository accountRepository;
@Bean
public TransferService transferService() {
return new TransferServiceImpl(accountRepository);
}
}
@Configuration
public class RepositoryConfig {
private final DataSource dataSource;
@Autowired
public RepositoryConfig(DataSource dataSource) {
this.dataSource = dataSource;
}
@Bean
public AccountRepository accountRepository() {
return new JdbcAccountRepository(dataSource);
}
}
@Configuration
@Import({ServiceConfig.class, RepositoryConfig.class})
public class SystemTestConfig {
@Bean
public DataSource dataSource() {
// return new DataSource
}
}
public static void main(String[] args) {
ApplicationContext ctx = new AnnotationConfigApplicationContext(SystemTestConfig.class);
// everything wires up across configuration classes...
TransferService transferService = ctx.getBean(TransferService.class);
transferService.transfer(100.00, "A123", "C456");
}
RepositoryConfig에서 accountRepository bean이 ServiceConfig에서 AccountRepository에 autowired됐어. config도 다 하나의 빈이라고 했으니 다른 곳에서 선언된 빈이 또다른 곳에서 autowired되어있는 모습이야.
@Configuration 클래스에서 생성자 주입은 오직 스프링 4.3에서 지원하는 내용이다. 만약 타겟 빈이 오직 한 생성자를 정의한다면 @Autowired가 필요없다. @AUtowired는 RepositoryConfig 생성자에서는 필요가 없다.
위의 예제를 보면 빈의 생성 시기에 따라 문제가 생길수도 있는 부분이라서, 생성자 주입 말고 setter 주입을 권장한다는 이야기.
쉽게 안내하기 위해 임포트된 빈에 자격을 주는 것
이 모호성이 받아들여지지않고 직접 IDE안에서 @Configuration 클래스에서 다른 것으로 직접 안내하고싶은 경우에 configuration 클래스를 연결하는것을 고려해보자.
@Configuration
public class ServiceConfig {
@Autowired
private RepositoryConfig repositoryConfig;
@Bean
public TransferService transferService() {
// navigate 'through' the config class to the @Bean method!
return new TransferServiceImpl(repositoryConfig.accountRepository());
}
}
이런 상황에서 AccountRepository는 완전하게 명시적으로 정의된다. 하지만 ServiceConfig는 이제 타이트하게 RepositoryConfig랑 커플링된다. 그것은 거래다. 이 타이트한 커플링은 다소 인터페이스나 추상클레스 기반 @Configuration 클래스보다 나을 수 있다. (!직접 어디의 클래스인지 명시적으로 작성)
@Configuration
public class ServiceConfig {
@Autowired
private RepositoryConfig repositoryConfig;
@Bean
public TransferService transferService() {
return new TransferServiceImpl(repositoryConfig.accountRepository());
}
}
@Configuration
public interface RepositoryConfig {
@Bean
AccountRepository accountRepository();
}
@Configuration
public class DefaultRepositoryConfig implements RepositoryConfig {
@Bean
public AccountRepository accountRepository() {
return new JdbcAccountRepository(...);
}
}
@Configuration
@Import({ServiceConfig.class, DefaultRepositoryConfig.class}) // import the concrete config!
public class SystemTestConfig {
@Bean
public DataSource dataSource() {
// return DataSource
}
}
public static void main(String[] args) {
ApplicationContext ctx = new AnnotationConfigApplicationContext(SystemTestConfig.class);
TransferService transferService = ctx.getBean(TransferService.class);
transferService.transfer(100.00, "A123", "C456");
}
interface에도 @Configuration을 사용할 수 있고, 이를 확장해서 구현함으로서 아까 위의 예제보다 결합도를 낮춘 방식으로 작성한 예제야.
이제 ServiceConfig는 루즈하게 DefaultRepositoryCOnfig를 쌓는 것과 커플링되고 IDE 내장 툴은 여전히 유용하다. : 쉽게 RepositoryConfig 확창체의 상하관계 타입을 얻을 수 있다. 이 방법으로 @Configuration클래스를 안내하는것과 의존성은 인터페이스 기반 코드를 안내하는 과정보다 다르지 않기 시작한다.
만약 특정 빈의 생성 순서에 영향을 끼치고 싶다면, @Lazy 를 쓰는것을 고려해보거나 (시작 대신에 처음 접근으로 생성) 특정한 다른 빈들에 @DependsOn을 쓰는 것을 고려해보자.(구체적인 다른 빈들이 현재 빈보다 전에 생성되고 늦게 생성된 것들을 직접적으로 의존하도록 하는)
조건부 @Configutaion 클래스들과 @Bean 메소드를 포함
@Profile : 상황에 맞게 설정이 바뀌어야하는 것을 지원. 이전에는 property 파일에 저장해두고 활용했는데 이 방법을 통해서도 같은 기능을 구현할 수 있다. (!Maven에서 상황에 맞게 빌드할 수 있는 거에서 난 활용했었어!)
@Profile 어노테이션은 사실 @Conditional이라고 리는 것 보다 훨씬 더 유용한 것으로 확장된 것이다. @Conditional 어노테이션은 @Bean이 등록되기 전에 상담해야만 하는 구체적인 org.springframework.context.annotation.Condition 확장체들을 가리킨다.
Condition 인터페이스의 확장체는 true 나 false를 반환하는 matches(...) 메소드를 제공한다. 예를 들어서, @Profile을 사용해서 실질적인 Condition 확장체를 보여준다.
@Override
public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
if (context.getEnvironment() != null) {
// Read the @Profile annotation attributes
MultiValueMap<String, Object> attrs = metadata.getAllAnnotationAttributes(Profile.class.getName());
if (attrs != null) {
for (Object value : attrs.get("value")) {
if (context.getEnvironment().acceptsProfiles(((String[]) value))) {
return true;
}
}
return false;
}
}
return true;
}
자바와 XML configuration 의 결합
스프링의 @Configuration 클래스 지원은 스프링 XML을 완전하게 대체하는 것을 목표로 하진 않는다. 스프링 XML 네임 스페이스 같은 일부 기능은 컨테이너를 구상하는 이상적인 방법이다. XML이 편리하거나 필요한 경우에는, 선택이 있다 : "XML-centric" 에서 컨테이너를 인스턴스화하거나(예를 들어서 ClassPathXmlApplicationContext) "Java-centric"에서 초기화 하는 방법이 있다.(AnnotationConfigApplicationContext와 @ImportResource어노테이션으로 필요한 XMl을 임포트하는)
XML 중심의 @Configuration 사용 (XML-centric)
XMl로 스프링 컨테이너 부트 스트랩을 선호할 수 있고, @Configuration 클래스를 ad-hoc방식으로 포함하고 싶을 수 있다. 예를 들어서 스프링 XML을 사용한 크게 존재하는 코드베이스에서 @Configuration 클래스는 as-needed 기반에서 생성하기 휩고 존재하는 XML 파일들로부터 그것들을 포함시킨다. 이 섹션 마지막에 @Configuration 클래스를 사용해서 "XML-centric"의 종류에서 옵션을 다뤄본다.
ad-hoc : 어떤 이론이나 학설, 논리에 대한 부정적인 근거나 반박이 나왔을떄 오직 그것에 대해서 반박하기 위해서만 필요한 가
기본 스프링 <bean/>요소로서 @Configuration 클래스를 선언
@Configuration 클래스들은 궁극적으로 컨테이너에 빈을 정의하기 위한 것임을 기억하자. 이 시리즈 예를 들면, 우리는 AppConfig라는 이름의 @Configuration 클래스를 생성하고 system-test-config.xml 에서 <bean/>정의로서 포함한다. <context:annotation-config/> 는 이 기능을 켜기 때문에 컨테이너는 @Configuration 어노테이션을 인식하고 AppConfig를 적절하게 전언한 @Bean 메소드를 작업한다.
아래는 configuration 클래스 예제다.
@Configuration
public class AppConfig {
@Autowired
private DataSource dataSource;
@Bean
public AccountRepository accountRepository() {
return new JdbcAccountRepository(dataSource);
}
@Bean
public TransferService transferService() {
return new TransferService(accountRepository());
}
}
아래는 샘플 system-test-config.xml파일의 일부분이다.
<beans>
<!-- enable processing of annotations such as @Autowired and @Configuration -->
<context:annotation-config/>
<context:property-placeholder location="classpath:/com/acme/jdbc.properties"/>
<bean class="com.acme.AppConfig"/>
<bean class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="url" value="${jdbc.url}"/>
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
</bean>
</beans>
public static void main(String[] args) {
ApplicationContext ctx = new ClassPathXmlApplicationContext("classpath:/com/acme/system-test-config.xml");
TransferService transferService = ctx.getBean(TransferService.class);
// ...
}
system-test-config.xml 파일에서 AppConfig<bean/>은 id 를 선언하지 않는다. 이렇게 하는게 허용될 수 있지만 다른 빈이 컨테이너를 참조하지 않는다면, 컨테이너는 불필요하다. 컨테이너에서 이름을 명시적으로 가져올 가능성은 없다. 유사하게 DataSource 빈은 오직 타입에 의해 자동연결되어서, 명시적인 빈 id는 강하게 요구되지 않는다.
@Configuration 클래스를 뽑기위해 <context:component-scan/>을 사용하는 것
@Configuration 은 @Component와 메타-어노테이트되어있기 때문에 @Configuration 으로 어노테이트된 클래스들은 자동적으로 컴포넌트 스캔의 후보가 된다. 같은 시나리오를 이전 예제에서 묘하한것 처럼 사용하는 것은, 컴포넌트 스캔의 이점을 취하기 위해 system-test-config.xml 을 재정의 할 수 있다. 이 경우에 명시적으로 <context:annotation-config/>를 선언할 필요가 없다. <context:component-scan/>이 같은 기능을 하기 때문에.
아래는 수정된 system-test-config.xml이다.
<beans>
<!-- picks up and registers AppConfig as a bean definition -->
<context:component-scan base-package="com.acme"/>
<context:property-placeholder location="classpath:/com/acme/jdbc.properties"/>
<bean class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="url" value="${jdbc.url}"/>
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
</bean>
</beans>
@ImportResource 를 사용하 XML 의 Class중심적 @Configuration 사용
@Configuration 클래스들은 컨테이너에서 configuring하기 위한 우선적 메카니즘이고, 최소한으로 XML을 사용할 가능성이 높다. 이 시나리오에선, @ImportResource를 사용할 수 고 필요한 만큼 XMl에서 정의할 수 있다. 그렇게 하는것은 컨테이너를 configuring하기 위해, 그리고 최소한으로 XML을 유지하기 위해 "Java-centric" 접근을 성취한다.아래 예지는(configuration 클래스, 빈을 정의한 XML파일 포함, 프로퍼티스 파일, 그리고 main 클래스)는 어떻게 @ImportResource어노테이션을 "Java-centric"을 사용하는지 보여준다.
@Configuration
@ImportResource("classpath:/com/acme/properties-config.xml")
public class AppConfig {
@Value("${jdbc.url}")
private String url;
@Value("${jdbc.username}")
private String username;
@Value("${jdbc.password}")
private String password;
@Bean
public DataSource dataSource() {
return new DriverManagerDataSource(url, username, password);
}
}
운이 좋게도, 이 문제를 푸는것은 간단하다. 우리가 이미 얘기 했듯이 ( ), @Bean 메소드는 빈 의존성을 서술하는 여러 임의의 파라미터를 가질 수 있다. 아래는 더 현실적인 시나리오이다.
시나리오를 예측하면, @Autowired 를 사용하는 것은 잘 동작하고 모듈화를 제공하지만 정의가 선언된 자동연결된 빈을 정확하게 결정하는 것은 여전히 모호하다. 예를 들어서, 개발자가 ServiceConfig를 찾을때 어떻게 정확하게 어디에 @Autowired AccountRepository 빈이 선언되어있는지 알 수 있을까? 이건 코드 내부에서 명시적이지 않고, 그냥 괜찮을지도 모른다. 는 어떻게 모든것들이 연결되는지 보여주는 그래프를 랜더링하는 툴을 제공하는 것을 기억해라. 또한 자바 IDE는 쉽게 모든 선언들을 찾을수 있고, AccountRepository 타입의 사용도 알 수 있다. 그리고 빠르게 그 타입을 반환하는 @Bean 메소드의 위치를 보여준다.
임의의 시스템 상태를 기반으로 전체 @Configuration 클래스나 개별 @Bean 메소드를 조건부로 활성화 하거나 비활성화하는 것이 유용한 경우가 많다. 예를 들어서 @Profile 어노테이션을 구체적인 프로필이 스프링 Environment에 사용 가능하도록할 때 빈들을 활성화하기 위해 쓴다.( 참조)
