Jars 내에 속성/구성 파일을 포함시키는 것은 나쁜 습관입니까?

Question

예 :

MyApp는 앱의 구성 데이터 (예 : 서버 이름)를 설명하는 속성 파일 (server.properties)이 포함 된 웹 앱입니다. 개발 단계에서 server.properties는 자체 IDE 프로젝트 폴더 (논리적 인 지점)에 있습니다.

이제 MyApp를 배포 할 차례입니다. IDE는 클래스 파일과 지원 설정 파일을 처리하는 것이 아주 간단합니다. 이제는 적절한 웹 컨테이너에 항아리를 떨어 뜨리면됩니다.

일주일 후 ... MyApp에서 사용하는 서버 구성 데이터를 변경해야합니다. 어느 것이 더 합리적입니까?

A. IDE 토지에서 server.properties 파일을 다시 수정하고 완전히 새로운 jar 파일을 생성하십시오. 재배포. (간단한 구성 변경을 위해 앱을 수신 거부하는 것을 의미).

B. 이미 배포 된 Jar를 열어서 server.properties 파일을 수정 하시겠습니까? (server.properties가 캐시 된 경우 MyApp에서 새로 고침 기능을 호출해야 할 수 있지만 전체 앱 바운스가 필요하지 않음) 또한 원본 server.properties도 기억해야하므로 향후 배포시 server.properties가 되돌아 가지 않습니다. 이전 서버 이름으로).

C. 먼저 server.properties 파일을 jar 파일 외부에 작성하십시오.

감사 : 단지 외부의 구성 데이터를 유지하는 작은 차이, B의 프로세스와 매우 유사

D. 기타 (배포 개발과 생산 사이의 서로 다른 경로를 소개합니다)!

Answer 1

나는 실패 할 경우, 항아리에 내장 된 속성을로드 한 후 .JAR 외부에서 특성 파일을로드하려고

D.

와 함께 갈 것입니다.

이렇게하면 각 빌드와 함께 "준비가 완료된"구성을 푸시 할 수 있으며 (단 하나의 파일 만 있으면 배포의 복잡성을 줄일 수 있음) 오버라이드 구성을 가능하고 합리적으로 간단하게 만듭니다.

Answer 2

에 달려 있습니다. 등록 정보 파일에 응용 프로그램이나 라이브러리의 사용자가 변경하려고하는 데이터가 들어 있으면 외부에 있어야합니다.

정적 인 데이터가 포함되어 있고 소스 코드의 값을 코딩하지 않도록 속성 파일을 만들었거나 파일이 지역화 된 문자열 인 경우 해당 파일을 항아리에 두는 것이 좋습니다. 최소한 속성 파일이 값을 변경하도록 사용자를 초대하기 때문에)

Answer 3

J2EE에서는 J2EE 환경 외부에서 파일에 액세스 할 수 있다는 보장이 없습니다 (직접 파일 액세스 없음).

JNDI를 사용하여 데이터가 포함 된 데이터 소스 또는 배포 아티팩트의 속성 파일을 지정해야합니다.

예를 들어, Websphere는 기본적으로 직접 파일 액세스를 허용하지 않습니다.

Answer 4

비슷한 질문을했습니다. 우리는 아직 그것을 전부 이해하지 못했습니다. 그러나 우리는 URL 리소스를 조사하고 있습니다. 여기서 속성 파일은 SVN에서 직접 읽습니다. 속성 파일 이외의 다른 것을 업데이트 할 필요가 없습니다.

Answer 5

종종 코드를 마이 그 레이션해야한다는 기준이 있습니다. UNCHANGED 테스트에서 프로덕션으로. 이는 임베디드 구성 파일을 편집 할 수 없음을 의미합니다. 또한 배포 된 구성을 변경해야하는 상황이 발생할 수 있으며, 이는 종종 매우 번거로울 수 있습니다. 그러므로 우리는 항아리 외부에 구성을 남겨 둡니다.

Java EE 응용 프로그램의 경우 JNDI 또는 클래스 경로의 등록 정보 파일을 고려하십시오.

이 웹 응용 프로그램은 이웃 웹 응용 프로그램에서 구성을 검색하여 둘을 구분합니다. 그게 훨씬 쉬워 졌어.

Answer 6

D.

로드 항아리에 등록. jar-ed 특성을 기본값으로 사용하여 새 특성을 작성하십시오. 그런 다음 항아리 외부에서로드하십시오. 이렇게하면 특성을 선택하여 사용자 정의 할 수 있습니다.

Answer 7

webapps (WARs)에서 속성 파일을 사용하지만 대개 기본값과 웹 앱이 WAR를 업데이트 할 수 없기 때문에 다소 불변합니다.

당신이 말하는 것에 대해 JNDI를 사용합니다. web.xml 파일에서 속성을 리소스로 정의 할 수 있습니다. 그렇게하면 최악의 경우 앱 자체가 아닌 web.xml을 업데이트합니다.

일부 서버의 경우 WAR를 전혀 건드리지 않고 이러한 자원 값을 무시하는 방법이 있습니다. 예를 들어, Tomcat에서.

보통 테스트, Q/A 및 프로덕션 용으로 하나의 WAR를 만들고 Tomcat의 컨텍스트 xml 파일을 사용하여 환경 적으로 중요한 리소스를 무시합니다. 여러 개의 WAR를 만들거나 WARS를 수정하는 것보다 훨씬 좋은 방법이라고 생각합니다. 테스트중인 앱이 프로덕션에있는 앱과 거의 동일하기 때문입니다.

Answer 8

나는 대답이 configs에 대한 버전 제어가 필요하다고 생각하는지에 달려 있다고 생각합니다. 당신이 좋은 하나 인 프로퍼티 파일을 무시 외부 프로퍼티 파일과 함께 다음 버전 제어, 옵션 D가 필요하지 않은 경우

• (그들은 ... 회귀 테스트를 위해 생산 CONFIGS 또는 CONFIGS 될 수있다). 옵션 B와 C는 좀 더 열심히 일합니다.하지만 실제로 버전 관리를 사용하고 싶다면
• 버전 관리가 필요하면 옵션 A를 사용하면 더 많은 제어가 가능하지만 여러 배포를 원할 수도 있고 각 배포의 구성을 버전 제어해야 할 수도 있습니다. 예는 테스트 및 프로덕션 플랫폼에 대한 별도의 배포입니다.

다음은 Maven 모듈과 Maven WAR 파일 "오버레이"를 사용하는 방법입니다.

1. Java 코드 구성 요소에는 여러 개의 모듈이 있습니다. 이들은 JAR 모듈입니다.
2. 정적 컨텐츠, JSP 및 핵심 구성 데이터 (스프링 배선, 기본 속성)를위한 "기본 webapp"모듈이 있습니다. 이것은 WAR 모듈이므로 빌드 결과는 위 + 모든 JAR 파일을 포함하는 WAR입니다.
3. 서로 다른 "사이트 구성"은 속성, 파일 및 와이어 링에 대한 사이트 별 재정의가 포함 된 WAR 모듈입니다. 오버라이드는 Maven WAR "오버레이"메커니즘을 사용하여 설명되며 "WAR"및 오버라이드로부터 새로운 WAR이 어셈블됩니다.

이 모든 것이 버전 제어로 점검되므로 구성을 변경하려면 Maven 빌드 및 WAR 배포가 필요합니다.

Answer 9

스프링을 사용하여 J2EE 응용 프로그램을 개발합니다. 나는 꽤 오랜 시간 동안 같은 문제를 해결하고 해결책을 찾았다. 문제점은 배치 한 war 파일 외부의 특성 파일에서 데이터베이스 특성을 지정하는 것이 었습니다. 나는이에 발견이 솔루션은이 같은 시스템의 위치를 ​​찾을 수 PropertyPlaceholderConfigurer와를 사용하여 위치 속성을 지정하려면이 매우 간단했다

이며 잘했다!

Answer 10

옵션 D.은 서로 다른 환경에서 당신은 등 데이터베이스 또는 프록시에 연결하는 등의 환경 속성을 지정하려면 지정해야 할 수도 있습니다

주목할 필요가

다른 점은 생산에 신속 속성을 변경할 수 있다는 것입니다 jar를 미리 패키지화하거나 jar의 특성 파일을 대체 할 필요가 없습니다.

예. 데이터베이스 서버가 떨어져서 다른 서버를 가리켜 야합니다 (데이터베이스의로드 밸런서를 사용하지 않는 경우). 따라서 데이터베이스 속성을 바꾸고 다시 시작하면됩니다. 거기에 많은 시간을 절약 할 수 있습니다.

Answer 11

당신이 Spring을 사용한다면 속성 플레이스 홀더를 사용하여 작업을 수행 할 수 있습니다.

<!-- try and resolve the config from the filesystem first and then fallback to the classpath --> 
<context:property-placeholder location="file:config.properties, classpath:config.properties" 
           ignore-resource-not-found="true"/> 

당신은 파일 시스템 또한 클래스 패스에 자원을 지정할 수 있습니다, 봄 먼저 시도하고 파일 시스템에서 모든 속성을 해결하고 클래스 패스에 폴백됩니다. "ignore-resource-not-found"속성을 "true"로 지정함으로써, 파일이 파일 시스템 상에 존재하지 않는 경우 Spring이 예외를 던지지 않게하고 클래스 패스에서 속성을 대신 해석하도록 허용합니다.

이 조합을 사용하면 두 파일에 대한 등록 정보를 분할 할 수 있습니다. 예를 들어 클래스 경로의 파일에 암호를 지정하지 않고 파일 시스템에서 외부 적으로 지정할 수 있습니다. 파일 시스템에서 누락 된 특성은 클래스 경로에서 분석됩니다. 모든 사람에게

# This file contains properties that are used to configure the application 
database.url=127.0.0.1 
database.port=3306 
database.user=root 
database.pass=p4ssw0rd