출처 : Outsider's Dev Story https://blog.outsider.ne.kr/
이 포스팅은 다음의 스프링소스 라이센스를 따릅니다.
이 문서는 개인적인 목적이나 배포하기 위해서 복사할 수 있다. 출력물이든 디지털 문서든 각 복사본에 어떤 비용도 청구할 수 없고 모든 복사본에는 이 카피라이트 문구가 있어야 한다.
1.3 사용 시나리오
앞에서 설정한 블락을 만드는 것은 많은 시나리오에서 스프링이 논리적인 선택을 하도록 한다. 여기서 많은 시나리오는 애플릿부터 스프링의 트랜잭션 관리 기능과 웹 프레임워크 통합을 사용하는 완전한 엔터프라이즈 어플리케이션까지를 포함한다.
대표적인 완전한 형태의 스프링 웹 어플리케이션
스프링의 선언적 트랜잭션 관리 기능은 웹 어플리케이션이 EJB 컨테이너가 관리하는 트랜잭션처럼 완전한 트랙잭션 기능을 가지게 한다. 모든 커스텀 비즈니스 로직은 간단한 POJO로 구현할 수 있고 스프링의 IoC 컨테이너로 관리할 수 있다. 추가적인 서비스는 이메일을 보내는 기능을 지원하고 어디서 유효성 확인 규칙을 실행할 것인지 선택하는 웹 계층과는 독립적인 유효성 확인에 대한 지원을 포함한다. 스프링의 ORM 지원은 JPA, Hibernate, JDO, iBatis와 통합되었다. 예를 들면 하이버네이트를 사용할 때 이미 존재하는 매핑 파일과 표준 하이버네이트 SessionFactory 설정을 계속 사용할 수 있다. 폼(Form) 컨트롤러는 도메인 모델에 대한 값으로 HTTP 파라미터를 전달하는 ActionForms나 다른 클래스에 대한 필요성을 제거함으로써 도메인 모델과 웹 계층을 자연스럽게 통합한다.
서드파티 웹 프레임워크를 사용하는 스프링 미들-티어
종종 다른 프레임워크로 완전히 전환하는 것이 어려울 수 있다. 스프링 프레임워크는 스프링 프레임워크안에서만 모든 일을 하도록 강제하지 않는다. 스프링 프레임워크는 스프링 프레임워크만 쓰던가 아예 쓰지 않던가 해야 하는 솔루션이 아니다. 이미 만들어진 프레임워크가 WebWork, Struts, Tapestry나 다른 UI 프레임워크로 만들어졌더라도 스프링의 트랜잭션 기능을 사용하는 스프링 기반의 미들-티어와 통합할 수 있다. 간단하게 ApplicationContext를 사용하는 비즈니스 로직을 연결하고 웹 계층과 통합하기 위해 WebApplicationContext 를 사용하면 된다.
원격 사용 시나리오
이미 존재하는 코드에 웹서비스로 접근할 필요가 있으면 스프링의 Hessian-, Burlap-, Rmi-나 JaxRpcProxyFactory 클래스를 사용할 수 있다. 존재하는 어플리케이션으로의 원격접근을 허용하는 것은 어렵지 않다.
EJB - 존재하는 POJO의 랩핑(Wrapping)
또 한, 스프링 프레임워크는 엔터프라이즈 자바빈, 존재하는 POJO의 재사용 허용, 선언적인 보안이 필요한 확장성 있고 안전한(fail-safe) 웹 어플리케이션에서 사용하는 무상태 세션빈을 감싸기 위해 접근과 추상화 계층을 제공한다.
1.3.1 의존성 관리와 작명 관례
의존성 관리과 의존성 주입은 다르다. 스프링의 좋은 기능(의존성 주입 같은)을 어플리케이션에서 사용하려면 필요한 모든 라이브러리(jar 파일)를 조립하고 런타임시에, 혹은 가능하다면 컴파일할 클래스패스에 둘 필요가 있다. 이러한 의존성은 주입되는 가상 컴포넌트가 아니라 (전통적으로) 파일시스템에 존재하는 물리적 리소스이다. 의존성 관리의 프로세스는 이러한 리소스를 필요한 위치에 두고 저장하고 클래스 패스에 추가하는 작업이 포함한다. 의존성은 직접적일 수도(예를 들어 런타임시에 스프링에 의존하는 어플리케이션) 간적접일 수도(예를 들어 commons-pool기반의 commons-dbcp에 의존하는 어플리케이션) 있다. 간적인 의존성은 보통 과도기적이라고 부르기도 하는데 이러한 의존성은 구별하고 관리하기가 몹시 어렵다.
스프링을 사용할 계획이라면 필요한 스프링 일부를 포함하는 jar 라이브러리의 복사본이 필요하다. 스프링은 의존성이 최대한 분리되도록 모듈이 패키징되어 있으므로 이 작업을 쉽게 할 수 있다. 예를 들어 웹 어플리케이션을 작성할 것이 아니라면 스프링-웹 모듈은 필요 없다. 이 가이드의 스프링 라이브러리 모듈을 참조하기 위해 spring-*나 spring-*.jar같은 짧은 작명 컨벤션을 사용한다. *은 모듈의 약칭을 의미한다. (예를 들어 spring-core, spring-webmvc, spring-jms등이다.) 실제 jar 파일명은 이 형식일 수도 있고(아래에서 볼 것이다) 아닐 수도 있으며 보통 파일명에 버전번호가 포함되어 있다.(예를 들면 spring-core-3.0.0.RELEASE.jar 와 같은 방식이다.)
보통 스프링은 결과물(Artifact)을 다음 네 곳에 배포한다.
- 커뮤니티 다운로드 사이트 http://www.springsource.org/downloads/community 다운로드받기 쉽도록 zip 파일로 묶인 모든 스프링 jar파일이 있다. 3.0 버전부터 이곳의 jar파일명은 org.springframework.*-<version>.jar 의 형식을 따른다.
- 메이븐 센트럴(Maven Central). 메이븐 센트럴은 메이븐의 기본 저장소이므로 사용하기 위해서 특별한 설정을 할 필요는 없다. 스프링이 의존하는 공통 라이브러리 중 다수는 메이븐 센트럴에서 이용할 수 있고 스프링 커뮤니티의 많은 부분은 의존성 관리에 메이븐을 사용하므로 편리하다. 메이븐 센트럴의 jar 파일명은 spring-*-<version>.jar의 형식을 따르고 메이븐 groupId는 org.springframework이다.
- SpringSource에서 운영하는 Enterprise Bundle Repository (EBR). EBR는 스프링에 통합하는 모든 라이브러리를 제공한다. 모든 스프링 jar와 의존성 라이브러리를 포함해서 그 외 스프링으로 어플리케이션을 개발할 때 사용하는 공통 라이브러리에 대한 메이븐 저장소와 아이비(Iby) 저장소를 모두 이용할 수 있다. 릴리즈 버전과 마일스톤을 포함해서 개발 스냅샷까지 이곳에 배포된다. jar 파일명은 커뮤니티 다운로드와 같은 형식(org.springframework.*-<version>.jar )을 사용하고 외부 라이브러리(스프링소스가 만들지 않은)는 com.springsource 접두사가 있는 긴 형식이다. 더 자세한 정보는 FAQ를 참고해라.
- 개발 스냅샵과 마일스톤 릴리즈를 위해 아마존 S2에서 운영되는 공개 메이븐 저장소를 사용한다.(최종 릴리즈의 복사본도 배포된다.) jar 파일명은 메이븐 센트럴과 같은 형식이므로 메이븐 센트럴에 배포된 다른 라이브러리와 함께 스프링의 개발 버전을 사용할 때 유용하다.
그래서 어떻게 의존성을 관리할 것인지를 먼저 결정해야 한다. 대부분은 메이븐이나 아이비같은 자동화된 시스템을 사용한다. 하지만 수동으로 모든 jar를 다운받아서 관리할 수도 있다. 메이븐이나 아이비로 스프링을 다운받으려면 어디서 다운받을 지를 결정해야 한다. 보통 OSGi를 고려한다면 Hibernate나 Freemarker같은 스프링 의존성의 OSGi 호환 결과물이 제공되는 EBR을 사용한다. OSGi를 쓸 계획이 없다면 저장소마다 장단점이 있지만, 어느 곳을 사용하던 큰 문제는 없다. 대신 섞어서 사용하지는 마라. EBR은 메이븐 센트럴과는 작명 관례를 사용하므로 특히 주의해야 한다.
Table 1.1. 메이븐 센트럴과 스프링소스 EBR 저장소의 비교
| 기능 | Maven Central | EBR |
|---|
| OSGi 호환 | 명확하지 않음 | 호환 |
| Artifact의 수 | 모든 종류로 수천 가지 | 스프링 통합과 관련된 것들로 수백 가지 |
| 작명 관례의 일관성 | 일관성 없음 | 일관성 있음 |
| GroupId의 작명 관례 | 다양함. 새로운 artifact는 종종 도메인 명을 사용한다. 예를 들면 org.slf4j. 오래된 것들은 그냥 artifact명을 사용한다. 예를 들면 log4j | 출처나 메인 패키지 루트의 도메인명. 예를 들어 org.springframework |
| ArtifactId의 작명 관례 | 다양함. 보통 프로젝트나 모듈명으로 구분자로 하이픈("-")을 사용한다. 예를 들면 spring-core, logj4 | 메 인 패키지 루트에서 유래된 번들 심볼릭명. 예를 들면 org.springframework.beans. jar가 OSGi 호환성 패치가 되었다면 com.springsource가 추가된다. 예를 들면 com.springsource.org.apache.log4j |
| 버전의 작명관례 | 다 양함. 새로운 artifact는 m.m.m이나 m.m.m.X를 사용한다. (m은 숫자고 X는 문자다.) 오래된 artifact는 m.m을 사용하거나 아예 다른 방식을 사용한다. 순서는 정의되어 있지만, 종종 따르지 않는 경우도 있으므로 너무 신뢰하지 않는 것이 좋다. | OSGi 버전번호인 m.m.m.X를 사용한다. 예를 들면 3.0.0.RC3. 텍스트는 숫처럼 버전의 순서가 지켜지는 알파벳만 사용할 수 있다. |
| 배포 | 보통 rsync나 소스제어 업데이트를 통해 자동으로 이루어진다. 프로젝트 저자는 JIRA로 각 jar를 업로드 할 수 있다. | 수동 (스프링소스가 처리하는 JIRA) |
| 품질 보증 | 정책에 의해서 이루어짐. 정확도에 대한 책임은 프로젝트 저자한테 있다. | 상세한 OSGi manifest, 메이븐 POM, 아이비 metadata를 따름. QA는 스프링 팀이 진행한다. |
| 호스팅 | Contegix. Sonatyle이 여러 미러사이트를 함께 펀딩함. | 스프링 소스가 펀딩하는 S3. |
| 검색 유틸리티 | 다양함 | http://www.springsource.com/repository |
| 스프링소스 도구의 통합 | 메이븐 의존성 관리로 STS에 통합됨 | 메이븐, Roo, 클라우드 파운드리와 함께 STS로 광범위하게 통합됨 |
1.3.1.1 스프링 의존성과 스프링에 기반하는 의존성
스프링이 엔터프라이즈와 다른 외부 도구들에 대한 광범위한 통합과 지원을 제공하더라도 의도적으로 의존성을 최소한으로 유지해야 한다. 간단한 사용을 위해서라면 많은 jar 라이브러리를 다운받아 설치하지 말아야 한다.(자동으로 한다고 하더라도) 기본적인 의존성 주입을 사용하려면 오직 하나의 외부 의존성만 필요하고 이는 로깅을 위한 것이다.(로깅 옵션에 대한 더 자세한 내용은 아래를 봐라.)
다음은 스프링에 의존하는 애플리케이션 설정하는 필요한 기본적인 과정을 설명할 차례다. 먼저 메이븐과 아이비를 사용한다. 모든 경우에서 명확한 것이 없다면 의존성 관리 시스템의 문서를 참고하거나 예제코드를 봐라. - 스프링은 개발과정에는 의존성 관리를 위해 아이비를 사용하고 예제는 대부분 메이븐을 사용한다.
1.3.1.2 메이븐 의존성 관리
메이븐으로 의존성을 관리한다면 로깅 의존성을 명시할 필요도 없다. 예를 들어 어플리케이션 컨텍스트을 생성하고 어플리케이션 설정에 의존성 주입을 사용하려면 메이븐 의존성은 다음과 같을 것이다.
Xml
1
2
3
4
5
6
7
8
| <dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>3.0.0.RELEASE</version>
<scope>runtime</scope>
</dependency>
</dependencies>
|
이것이 전부다. 스프링 API를 거슬러서 컴파일할 필요가 없다면 scope를 런타임으로 선언할 수 있다. 이는 기본적인 의존성 주입의 유즈케이스다.
위의 예제에서 메이븐 센트럴의 작명 관례를 사용했으므로 메이븐 센트럴이나 스프링소스의 S3 메이븐 저장소에서 동작한다. S3 메이븐 저장소를 사용하려면(예를 들어 마일스톤이나 개발 스냅샷을 사용하기 위해) 메이븐 설정에 저장소의 위치를 명시해야 한다. 전체 릴리즈를 사용하려면 다음과 같이 작성한다.
Xml
1
2
3
4
5
6
7
| <repositories>
<repository>
<id>com.springsource.repository.maven.release</id>
<url>http://maven.springframework.org/release/</url>
<snapshots><enabled>false</enabled></snapshots>
</repository>
</repositories>
|
마일스톤을 사용하려면 다음과 같이 작성한다.
Xml
1
2
3
4
5
6
7
| <repositories>
<repository>
<id>com.springsource.repository.maven.milestone</id>
<url>http://maven.springframework.org/milestone/</url>
<snapshots><enabled>false</enabled></snapshots>
</repository>
</repositories>
|
개발 스냅샷을 사용하려면 다음과 같이 작성한다.
Xml
1
2
3
4
5
6
7
| <repositories>
<repository>
<id>com.springsource.repository.maven.snapshot</id>
<url>http://maven.springframework.org/snapshot/</url>
<snapshots><enabled>true</enabled></snapshots>
</repository>
</repositories>
|
스프링소스의 EBR을 사용하려면 의존성에 대해서 앞에서와는 다른 작명 관례를 사용해야 한다. 이름은 예하기 쉽다. 예를 들면 다음과 같다.
Xml
1
2
3
4
5
6
7
8
| <dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>org.springframework.context</artifactId>
<version>3.0.0.RELEASE</version>
<scope>runtime</scope>
</dependency>
</dependencies>
|
저장소의 위치도 명시적으로 선언해야 한다.(URL부분만 중요하다)
Xml
1
2
3
4
5
6
| <repositories>
<repository>
<id>com.springsource.repository.bundles.release</id>
<url>http://repository.springsource.com/maven/bundles/release/</url>
</repository>
</repositories>
|
직접 의존성을 관리한다면 위에서 선언한 저장소 URL은 검색하기에 좋지 않다. 하지만 http://www.springsource.com/repository에서 의존성을 검색하고 다운로드 받을 수 있는 화면을 제공한다. 메이븐이나 아이비를 사용한다면 쉽게 복사해서 붙일 수 있도록 메이븐과 아이비 설정 스니펫을 제공한다.
1.3.1.3 아이비(Ivy) 의존성 관리
의존성 관리를 Ivy로 하길 좋아하더라도 라이브러리 이름과 설정옵션은 비슷하다.
아이비를 설정하려면 ivysettings.xml에 스프링소스 EBR을 나타내는 다음 resolver를 추가한다.
Xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| <resolvers>
<url name="com.springsource.repository.bundles.release">
<ivy pattern="http://repository.springsource.com/ivy/bundles/release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
<artifact pattern="http://repository.springsource.com/ivy/bundles/release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
</url>
<url name="com.springsource.repository.bundles.external">
<ivy pattern="http://repository.springsource.com/ivy/bundles/external/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
<artifact pattern="http://repository.springsource.com/ivy/bundles/external/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
</url>
</resolvers>
|
위의 XML은 라인이 너무 길어서 유효한 XML이 아니다. - 복사해서 붙다면 URL 가운데 줄 바꿈을 삭제해라
아이비가 EBR로 설정되면 의존성 추가는 쉽다. 저장소 검색페이지에서 원하는 라이브러리의 상세페이지에 들어가서 의존성 부분에 추가할 아이비 스니펫을 찾을 수 있다. 예를 들어 ivy.xml에 다음과 같이 추가한다.
<dependency org="org.springframework"
name="org.springframework.core" rev="3.0.0.RELEASE"
conf="compile->runtime"/>
1.3.2 로깅
스프링에서 로깅은 아주 중요한 의존성이다.
그 이유는
a) 로깅은 유일하게 강제적인 외부 의존성이고,
b) 개발자는 사용하는 도구에서 어떤 출력을 보기 원하고
c) 스프링은 로깅 의존성의 선택이 있는 다른 많은 툴과 통합되기 때문이다.
어플리케이션 개발자의 목표 중 하나는 외부 컴포넌트를 포함한 전체 어플리케이션의 중심에서 통일된 로깅을 설정하는 것이다. 이는 로깅 프레임워크가 많이 존재하기 때문에 쉽지 않다.
스프링의 강제적인 로깅 의존성은 Jakarta Commons Logging API (JCL)이다. JCL을 컴파일하고 스프링 프레임워크를 상속받은 클래스에서 사용할 수 있는 Log객체로 만든다. 이는 같은 로깅 라이브러리를 사용하는 모든 버전의 스프링 사용자에게 중요하다. 스프링은 스프링을 상속받은 어플리케이션에서조차 하위호환성이 유지되므로 마이그레이션이 쉽다. 마이그레이션을 하는 방법은 스프링의 모듈 중 하나를 명시적으로 commons-logging(JCL의 정식 구현체)에 의존하게 하고 다른 모듈은 컴파일 시에 의존하게 하는 것이다. 예를 들어 메이븐을 사용하는데 commons-logging의 의존성이 어디에 있는지 모른다면 스프링의 핵심모듈인 spring-core에 있다.
commons-logging의 좋은 점은 당신이 어플리케이션을 동작하게 하는 것에만 신경 쓰면 된다는 것이다. commons-logging에는 잘 알려진 클래스패스나 적절한 위치(필요하다면 지적할 수 있다.)에서 다른 로깅 프레임워크를 찾는 런타임 디스커버리 알고리즘이 있다. 이용할 수 있는 로깅 프레임워크가 없다면 JDK(정확히는 java.util.logging이나 JUL이다.)로 꽤 괜찮은 로그를 남긴다. 대부분 상황에서 로그가 잘 나오는 것을 확인해서 스프링이 잘 동작한다는 것을 알 수 있다. 이는 중요하다.
1.3.2.1 Commons Logging 사용하지 않기
안타깝게도 commons-logging의 런타임 디스커버리 알고리즘은 엔드유저에게는 편리하지만, 문제의 소지가 있다. 시간을 거꾸로 돌릴 수 있거나 스프링을 새로운 프로젝트로 다시 시작한다면 런타임 디스커버리 알고리즘은 다른 로깅 의존성을 사용할 것이다. 첫 번째 선택은 아마 Simple Logging Facade for Java (SLF4J)일 것이다. 어플리케이션에서 스프링과 함께 사용하는 많은 툴은 SLF4J를 사용한다.
commons-logging는 쉽게 사용하지 않게 할 수 있다. 그냥 런타임시에 클래스패스에 존재하지 않으면 된다. 스프링 의존성이 선언되어 있으므로 메이븐에서 의존성을 제외 처리하면 된다.
Xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| <dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>3.0.0.RELEASE</version>
<scope>runtime</scope>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
|
위 코드를 추가하면 어플리케이션의 빌드가 깨질 것이다. 클래스패스에 JCL API의 구현체가 없기 때문이다. 새로운 구현체를 추가하면 이 문제를 해결할 수 있다. 다음 섹션에서 예제를 통해 SLF4J를 사용하는 JCL 구현체를 새로 추가하는 방법을 살펴볼 것이다.
1.3.2.2 SLF4J의 사용
SLF4J는 의존성이 깔끔하고 commons-logging보다 런타임에서 더 효율적이다. 다른 로깅 프레임워크의 런타임 디스커버리 대신 컴파일할 때 바인딩하기 때문이다. 이는 런타임에서 벌어질 일을 더 명시적으로 지정해야 한다는 의미이다. 따라서 의존성을 선언하고 적절하게 설정해야 한다. SLF4J는 대부분의 로깅 프레임워크에 대한 바인딩을 지원하므로 기존에 사용하던 로깅 프레임워크를 계속 사용할 수 있다. 사용하는 로깅 프레임워크를 설정과 관리에 바인딩하면 된다.
SLF4J는 JCL을 포함한 많은 로깅 프레임워크에 대한 바인딩을 지원한다. 반대로 다른 로깅 프레임워크가 SLF4J로 바인딩할 수도 있다. 즉 다른 로깅프레임워크와 SLF4J사이에 브릿지로 사용할 수도 있다. 그래서 스프링과 SLF4J를 함께 사용하려면 commons-logging의존성을 SLF4J-JCL 브릿지로 바꿔야 한다. 설정을 바꾸었으면 스프링에서 호출된 로깅은 SLF4J API를 호출하는 로깅으로 전환된다. 그래서 어플리케이션의 다른 라이브러리가 같은 API의 로깅을 사용한다면 한 곳에서 로깅을 설정하고 관리할 수 있다.
스프링을 SLF4J로 브릿지하고 명시적으로 SLF4J를 Log4J로 바인딩하는 것이 가장 일반적이다. 브릿지, SLF4J API, Log4J로의 바인딩, Log4J구현체의 4가지 의존성을 추가해야 한다.(commons-logging는 제외 처리해야 한다.) 메이븐이라면 다음과 같이 추가한다.
Xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
| <dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>3.0.0.RELEASE</version>
<scope>runtime</scope>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.5.8</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.5.8</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.5.8</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.14</version>
<scope>runtime</scope>
</dependency>
</dependencies>
|
단순히 로깅을 사용하기 위해 너무 많은 의존성을 추가한 것처럼 보일 수 있다. 하지만 이는 선택사항이고 평범한 commons-logging보다 나은 동작을 한다. 특히 commons-logging는 OSGi 플랫폼 같은 엄격한 컨테이너를 사용한다면 클래스로더 이슈도 고려해야 한다. 또한, 바인딩이 런타임이 아닌 컴파일타임에 이뤄지기 때문에 성능적인 이점도 있다고 알려졌다.
더 적은 과정과 의존성을 사용하는 SLF4J 사용자들은 보통 Logback로 직접 바인딩한다. Logback은 SLF4J를 직접 구현했기 때문에 추가적인 바인딩 과정을 줄여준다. 그래서 4개가 아닌 2개의 라이브러리에만 의존할 수 있다.(jcl-over-slf4j와 logback) Logback으로 직접 바인딩하는 방법을 사용했다면 (스프링이 아닌) 다른 외부 의존성에서 slf4j-api에 대한 의존성을 제외처리 해야 한다. 이는 클래스패스에 오직 한가지 버전의 API만 존재하기를 바라기 때문이다.
1.3.2.3 Log4J의 사용
많은 사람들이 설정과 관리 때문에 로깅 프레임워크로 Log4j를 사용한다. Log4j는 사용하기 편하고 잘 구성되어 있다. 사실 스프링을 만들고 테스트할 때 런타임에서 Log4j를 사용했다. 스프링은 Log4j의 설정과 초기화를 위한 몇 가지 유틸리티도 제공한다. 그래서 스프링의 몇몇 모듈에는 Log4j에 대한 의존성이 컴파일타임에 선택적으로 의존성이 존재한다.
기본 JCL 의존성(commons-logging)과 함께 Log4j가 동작하게 하려면 클래스패스에 Log4j를 두고 클래스패스의 루트에 설정파일 (log4j.properties나 log4j.xml)을 두면 된다. 메이븐 사용자라면 의존성 선언에 추가한다.
Xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| <dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>3.0.0.RELEASE</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.14</version>
<scope>runtime</scope>
</dependency>
</dependencies>
|
다음은 콘솔에 로그를 출력하는 log4j.properties의 예제이다.
log4j.rootCategory=INFO, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %t %c{2}:%L - %m%n
log4j.category.org.springframework.beans.factory=DEBUG
네이티브 JCL를 사용하는 런타임 컨테이너
많은 사람들이 JCL의 구현체를 제공하는 컨테이너에서 스프링 어플리케이션을 구동한다. IBM 웹스피어(Websphere) 어플리케이션 서버(WAS)가 대표적이다. 웹스피어는 종종 문제를 일으키는데 불행히도 거기에는 완벽한 해결책이 없다. 대부분의 상황에서 단순히 어플리케이션에서 commons-logging를 제외 처리하는 것으로는 해결되지 않는다.
이 문제를 좀 더 명확히 보자. 알려진 문제점은 JCL이나 commons-logging자체의 문제는 아니다. 더 정확히 말하면 commons-logging를 다른 프레임워크(대개 Log4J)로 바인딩해서 발생한 문제다. 바인딩이 실패하는 이유는 몇몇 컨테이너가 사용하는 commons-logging의 과거 버전(1.0)과 대부분이 사용하는 최신 버전(1.1)사이에서 런타임 디스커버리 방법이 달라졌기 때문이다. 스프링은 JCL API에서 특이한 API는 전혀 사용하지 않으므로 문제가 발생하지 않는다. 하지만 스프링이나 어플리케이션이 로깅을 시도하자마자 Log4J로의 바인딩이 동작하지 않는 것을 발견할 수 있을 것이다.
WAS에서 이러한 상황을 겪을 가장 쉬운 해결책은 컨테이너 대신 어플리케이션이 JCL 의존성을 제어하도록 클래스 로더의 계층을 거꾸로 하는 것이다.(IBM은 이를 "parent last"라고 부른다.) 이 옵션은 항상 열려 있는 것은 아니지만, 대안적인 방법을 위한 공개된 영역에서 다수의 다른 제안이 존재한다. 아마 컨테이너의 정확한 버전과 기능에 의존하도록 바꿀 것이다.
