의존성 주입 : 여러 구성을 유지하는 방법?

Question

아주 잘 작동하는 DI 프레임 워크로 시스템을 구축했다고 가정 해 보겠습니다. 이 시스템은 현재 JMS를 사용하여 우리가 관리하지 않는 다른 시스템과 "대화"합니다. 우리 고객의 대다수는 JMS 접근 방식을 좋아하고 우리의 사양에 따라 사용합니다. 모든 메시징을 수행하는 컴포넌트는 Spring과 함께 나머지 애플리케이션에 삽입된다.

이제 한 고객이 JMS 솔루션을 구현할 수없고 다른 메시징 기술을 사용하고자하는 경우가 있습니다. 이 기술을 사용하여 메시징 서비스를 구현하고 나머지 응용 프로그램에 삽입하기 만하면되므로 문제가되지 않습니다.

하지만 구성의 배포 및 유지 관리는 어떻게 처리해야합니까? 응용 프로그램이 Spring을 사용하기 때문에이 응용 프로그램에 대한 모든 구성을 확인하고 시스템 관리자가 응용 프로그램을 시작하고로드 할 구성을 지정하기 위해 DI XML 파일의 이름을 전달할 수 있습니다. 그러나 ... 그것은 단지 옳다고 생각하지 않습니다. 그러한 경우에 대한 해결책이 있습니까? 당신이 사용하는 모범 사례는 무엇입니까? 심지어 하나의 서비스 대체만을 포함하지 않는 더 복잡한 시나리오를 상상할 수도 있습니다 ...

고마워요!

Answer 1

또 다른 제안은 다음과 같습니다. 스프링 구성을 두 부분으로 나누는 방법 : 모든 사용자에게 제공되는 공통 파일과 다양한 Bean 정의를 보유하는 배치 별 파일. . 그래서 당신은 할 수 : 당신의 SYS의 관리자가 배포 할 때

applicationCommon.xml 
deploymentJMS.xml 
deploymentOtherMessaging.xml 
deploymentDifferentAgainMessaging.xml 

그런 다음, 그들은 배포 ???의 하나 선택 XML 파일을 시나리오에 따라하고 config 디렉토리

에 놓으 귀하 응용 프로그램은 와일드 카드 표현식을 사용하여 applicationCommon.xml 파일과 다른 모든 xml 파일을 config 디렉토리에로드하여 응용 프로그램 컨텍스트를 빌드하는 데 함께 사용하여 (실제로 어떤 실제 파일을 다루지 않고) 구성됩니다.

다른 배포 XML 파일은 소스 제어에 있으므로 sysadmin은 시나리오에 적합한 명명 된 deployment ???. XML 파일을 항상 배포한다는 것을 알기보다는 자세한 지식이 필요하지 않습니다.

(자사의 웹 애플리케이션, 당신은 응용 프로그램의 재 배포 배포 고유의 설정을 덮어 쓰지 않았다 있도록 "설정"디렉토리, 웹 응용 프로그램 자체에서 분리해야 할 수 있습니다 경우) 물론이 배포는 모두 스크립트로 작성 될 수 있으므로 명령 줄 매개 변수로 올바른 파일을 선택해야합니다. 예를 들면 다음과 같습니다.

Answer 2

한 가지 해결책은 Spring 구성에서 PropertyOverrideConfigurer를 사용하는 것입니다. 이렇게하면 응용 프로그램 컨텍스트가 시작될 때 Spring 구성의 값을 대체 할 수있는 별도의 특성 파일을 제공 할 수 있습니다. 그렇게하면 applicationContext.xml (모든 사용자에게 제공)에 표준 구성이 있고 기본 구성 파일을 변경하지 않고도 배포별로 기본 구성을 사용자 지정할 수있는 추가 등록 정보 파일이 있습니다.

<bean class="org.springframework.beans.factory.config.PropertyOverrideConfigurer"> 
    <property name="location"><value>file:${config.dir}/config.properties</value></property> 
</bean> 

Answer 3

나는 여러 가지 버전의 제품을 제공하거나 두 메시징 시스템을 모두 지원하는 제품을 선택해야한다고 생각합니다.

나는 단일 제품을 선호합니다. 고객 관리자가 메시징 시스템을 정의하는 매개 변수를 설정하지 않도록하려면 고객 별 구성 파일을 제공하거나 해당 정보를 라이센스 파일에 추가하여 고객이 사용하는지 확인하십시오. 올바른 버전.

메시징 시스템이 비 자유형 타사 라이브러리에 의존하는 경우에만 라이센스 문제를 방지하기 위해 다양한 제품을 구축합니다.

Answer 4

우리는이 제품과 똑같은 사용 사례를 가지고 있습니다.

각 구성 집합마다 서로 다른 applicationContext 파일 집합을 만들었습니다. 컨텍스트 파일은 이미 네 개의 서로 다른 파일 (-servlet.xml, -services.xml, -dao.xml 등)로 나뉘며 동일한 "구성 집합"의 각 파일은 동일한 접두사를 파일 이름에 공유합니다.

이 제품에서는 Ant를 사용하여 배포 파일 (.war)을 빌드합니다. build.xml을 설정하여 빌드 스크립트에 다른 매개 변수를 전달하여 파일을 패키징 할 때 사용되는 접두사를 제어 할 수 있습니다. 예를 들어, 우리는 app1-dao.xml, app1-services.xml로 만든 배치 파일 등의 포장을 가지고

ant dist -DtargetApp=app1 

를 실행합니다. 이 제품은 웹 응용 프로그램의 ${targetApp} 속성 값이기 때문에

<target name="set-environment"> 
    <!-- If the targetApp property is not set, default to "app1" --> 
    <condition property="targetApp" value="app1"> 
     <not> 
      <isset property="targetApp"/> 
     </not> 
    </condition> 
    <echo>Using targetApp: ${targetApp}</echo> 
<target> 

: 개미 내

, 우리는 "구성 스위트"이름을 사용하는 속성을 설정하려면이 같은 형태의 논리를 가지고 그런 다음 web.xml의 값을 필터링하여로드 할 응용 프로그램 컨텍스트 파일을 Spring에 알립니다.