5.7. Diagnosing problems

여러분이 사용하기로 선택한 OSGi 플랫폼 구현체는 현제 OSGi 환경 상태에 대한 정보를 잘 제공해 주어야 한다. 예를 들어, -console 아규먼트를 Equinox 시작시 추가하면 커맨드 라인 콘솔을 제공한다. 이것을 통해 어떤 번들들이 설치되어 있고 그들의 상태와, 해당 번들에 의해 공개된 패키지와 서비스, 번들 Resolve 실패 원인, 번들 라이프사이클 다루기 등을 할 수 있다.

게다가, 스프링 자체와 스프링 DM 번들은 문제의 원인을 조사할때 사용할 수 있는 확장 가능한 로깅 체계가 마련되어 있다. Simple Logging Facade for Java(slf4j) slf4j.jar 와 slf4j-log4j13.jar 번들을 설치하길 권장한다. 그렇게만 하면, 번들 클래스패스 루트에 log4j.properties 파일을 생성하여 사용할 수 있다.

스프링 DM 모듈은 commons-logging API를 내부적으로 사용하고 있는데, 이것은 로깅 구현체가 완전히 끼워맞출 수 있는pluggble 형태로 개발되었다는 것을 의미한다.

5.6. Considerations when using external libraries

대부분의 엔터프라이즈 애플리케이션 라이브러리들은 context class loader를 통해서 타입과 리소스를 로딩할 수 있다고 가정한다. 보통 개발자가 이 것을 직접 다루지는 않지만, 애플리케이션 서버, 컨테이너 또는 멀티 쓰레드로 동작하는 애플리케이션들은 context class loader를 사용하고 있다.

OSGi R4에서는 context class loader를 통해 가용한 타입이나 리소스 집합에 대해 정의되어 있지 않다. 이것은 OSGi 플랫폼이 쓰레드 context class loader 값을 보장하지 못한다는 것이고 다시 말하자면, ccl을 관리하지 않는다는 것이다.

따라서 클래스 로딩을 하거나 동적으로 새로운 클래스를 생성하는 코드가 OSGi 환경에서는 제대로 동작하지 않을 수 있다.

스프링 DM은 해당 번들의 application context를 생성하는 도중에 번들의 클래스패스에서 가용한 모든 타입과 리소스들을 ccl을 통해 접근할 수 있도록 보장한다. 또한 스프링 DM은 외부 서비스를 호출할 때와 공개한 서비스에 대한 요청에 서비스를 할 때 CCL을 통해서 접근 가능한 클래스와 리소스를 설정할 수 있다. 방법은 5.5에서 설명했다.

OSGi R5에서는 제 3의 라이브러리에 의해 추가된 암묵적인 클래스 패스와 생성된 클래스를 지원하기 위한 스펙을 정하고 있다. 그전까지는 DynamicImport-Package manifest 헤더를 사용하거나,  Equinox의 버디buddy 매커니즘을 사용할 수 있을 것이다.

5.5. Importing and Exporting packages

Import-Package와 Export-Package manifest 헤더에 대한 자세한 내용은 OSGi 스펙을 참조하도록.

번들은 자신이 의존성을 가지는 모든 외부 패키지들을 Import-Package를 사용해서 설정한다.

만약 다른 번들들이 사용할 필요가 있는 타입을 제공해야 한다면, Export-Package를 사용하여 외부 번들에서 사용할 수 있는 모든 패키지를 설정한다.

5.4. Spring XML authoring support

스프링 2.0은 보다 쉬운 XML 설정과 확장 가능한 XML을 도입했다. 이 중 후자는 커스텀 스키마를 만들어 스프링 XML 인프라가 자동으로 해당 설정을 읽을 수 있는 것이 가능해졌다. 그냥 그것들을 클래스패스에 두기만 하면 된다.(이 부분은 토비 사부님이 1회 KSUG에서 발표하셨던 내용) 스프링 DM은 이 기본 지식을 활용해서 OSGi 환경에서 부가적인 코드나 menifest 선언 필요 없이 커스텀 스키마를 사용할 수 있도록 했다.

Spring DM은 OSGi 공간에 배포되는 모든 번들(스프링 DM 번들이든 아니든 상관없이)들을 조사하여 커스텀 스프링 네임스페이스 선언을 가지고 있는지 스캔한다.(META-INF/spring.handlers 와 META-INF/spring.schemas 번들 영역을 확인한다.) 만약에 해당하는 선언을 찾으면, 스프링 DM은 해당 스키마를 만들고 해당 네임스페이스는 OSGi 서비스를 통해서 자동으로 스프링 번들에 의해 사용이 가능해진다

=> 즉, 커스텀 스키마를 사용하는 번들을 배포할 때 필요한 건, 네임스페이스 파서와 스키마를 제공하는 라이브러리를 OSGi 플랫폼에 배포하기만 하면 된다는 것이다.

번들의 클래스 패스 내부에 있는 커스컴 스키마는 OSGi 공간에서 다른 번들들에 의해 사용될 수 있다. 하지만, 번들 내부 라이브리의 네임스페이스는 다른 번들들에의해 공유되지 않는다. 다른 번들들이 볼 수 없다.

=> 번들로 배포된 네임스페이스만 공개 되고, 내장된 라이브러리의 네임스페이스는 공개하지 않음.

스프링 DM을 사용하면, 커스컴 네임스페이스 기능을 어떠한 부가작없도 필요없이 투명하게 지원한다. 내장된 네임스페이스 제공자(Embedded namespace provider)들은 우선권을 가지지만 공유하지는 않는다. 이와 반대로 번들로 배포된 제공자(providers deployed as bundle)들은 다른 번들들에서 참조할 수 있다.

5.3. Required Spring Framework and Spring Dynamic Modules Bundles

스프링 Extender가 제대로 동작하려면 OSGi 플랫폼에 배포해야 할 몇몇 번들 아티팩트들이 있다.
– org.springframework.osgi.extender : extender 번들 자신
– org.springframework.osgi.core : 스프링 DM을 지원하는 핵심 구현체 변들
– org.springframework.osgi.io : 스프링 DM I/O 지원 라이브러리 번들

여기에 추가로 스프링 라이브러리가 필요한데, 스프링 2.5부터는 OSGi 플랫폼에 바로 배포가 가능한 형태로 배포하고 있다. 그 중에 다음을 필요로 한다.
– spring-core.jar
– spring-context.jar
– spring-beans.jar
– spring-aop.jar

추가로 다음의 라이브러리 번들을 필요로 한다. OSGi 플랫폼에 배포 가능한 형태의 JAR 파일들을 Spring DM With Dependencies 형태로 배포한 파일에 들어있다.
– aopalliance
– backport-util(JDK 1.4에 돌릴 때만 필요)
– cglib-nodep
– commons-logging API(SLF4J 강추)
– logging 구현체