[SPRING] 다른 환경에서 스프링 빈을 정의 할 때 일반적인 전략

다른 환경에서 스프링 빈을 정의 할 때 일반적인 전략

개발 환경과 생산 환경에서 다르게 사용되는 빈을 정의하는 일반적인 전략은 무엇입니까?

두 개의 빈이 있고 각각이 동일한 인터페이스를 구현한다고 가정 해 보겠습니다. 하나의 bean은 로컬 파일 시스템의 추상화 역할을하고 다른 하나는 분산 파일 시스템에 연결합니다. 개발을 안정적으로 유지하려면 개발 환경에서 로컬 파일 시스템 구현을 사용해야하고 제작 릴리스에서는 분산 파일 시스템 빈을 사용해야합니다.

현재 내가하고있는 것은 두 개의 XML 정의를 갖는 것입니다.

native.xml

<bean id="resourceSystem" class="com.cust.NativeResourceSystem" />

distributed.xml

<bean id="resourceSystem" class="com.cust.HadoopResourceSystem">
    <constructor-arg name="fs" ref="hdfs" />
</bean>

응용 프로그램 컨텍스트를 만들 때 환경에 따라 native.xml 또는 distributed.xml을 생략하고 resourceSystem bean을 가져옵니다.

다른 환경을위한 bean 정의를 설정하기 위해 Spring에서 적절한 툴이나 베스트 프랙티스가 있습니까?

감사.

해결법

1. ==============================

   1.다음은 Spring 참조 문서에서 PropertyPlaceholderConfigurer에 대한 설명입니다.

   다음은 Spring 참조 문서에서 PropertyPlaceholderConfigurer에 대한 설명입니다.

   위에서 볼 수 있듯이 Java System 속성을 설정할 수 있습니다.

   개발 기계에서

   -Dprofile=development
   

   On 생산 기계

   -Dprofile=production
   

   따라서 다음과 같이 각 계층 컨텍스트 설정을 가져 오는 전역 응용 프로그램 컨텍스트 설정을 정의 할 수 있습니다

   <?xml version="1.0" encoding="UTF-8"?>
   <beans xmlns="http://www.springframework.org/schema/beans"
          xmlns:context="http://www.springframework.org/schema/context"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.springframework.org/schema/beans
                              http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
                              http://www.springframework.org/schema/context
                              http://www.springframework.org/schema/context/spring-context-2.5.xsd">
       <context:property-placeholder/>
       <import resource="service-${profile}.xml"/>
       <import resource="persistence-${profile}.xml"/>
       <import resource="security-${profile}.xml"/>
   </beans>
   

   모든 위치 경로는 가져 오기를 수행하는 정의 파일과 관련이 있습니다

   따라서 이런 종류의 설정은 Spring에 의해 지원된다.

2. ==============================

   2.이것이 제가 많은 프로젝트에서 사용해온 것입니다. 모든 환경에 독립적 인 bean을 common.xml로하고 다른 모든 것을 dev.xml / qa.xml / prod.xml에 있습니다. 개미를 사용하여 프로젝트를 빌드하는 경우 환경을 빌드 프로세스의 인수로 제공하고 빌드 스크립트에 적절한 env.xml을 포함시키고 다른 것을 생략하도록하십시오. 내 말은, 빌드 스크립트는 dev.xml을 env.xml로, dev 환경을 env.xml로, qa.xml을 QA로 복사합니다. 따라서 빈 정의를로드하는 코드는 항상 "common.xml, env.xml"을 사용합니다.

   이것이 제가 많은 프로젝트에서 사용해온 것입니다. 모든 환경에 독립적 인 bean을 common.xml로하고 다른 모든 것을 dev.xml / qa.xml / prod.xml에 있습니다. 개미를 사용하여 프로젝트를 빌드하는 경우 환경을 빌드 프로세스의 인수로 제공하고 빌드 스크립트에 적절한 env.xml을 포함시키고 다른 것을 생략하도록하십시오. 내 말은, 빌드 스크립트는 dev.xml을 env.xml로, dev 환경을 env.xml로, qa.xml을 QA로 복사합니다. 따라서 빈 정의를로드하는 코드는 항상 "common.xml, env.xml"을 사용합니다.

3. ==============================

   3.이 기능은 SpringSource의 레이더에 있으며 향후 릴리스에서 사용할 예정입니다.

   이 기능은 SpringSource의 레이더에 있으며 향후 릴리스에서 사용할 예정입니다.

   여기와 여기를 참조하십시오.

from https://stackoverflow.com/questions/3484591/common-strategies-when-defining-spring-beans-for-different-environments by cc-by-sa and MIT license