공유 라이브러리에서 기본 라이브러리 구성

기본 라이브러리는 공유 라이브러리 내에서 구성될 수 있는 플랫폼 특정 라이브러리 파일(.dll, .so 또는 *SRVPGM 오브젝트 포함)입니다. 기본 라이브러리는 공유 라이브러리가 애플리케이션과 연관될 때마다 애플리케이션 클래스 로더에서 볼 수 있습니다. 이와 유사하게 기본 라이브러리는 공유 라이브러리가 애플리케이션 서버와 연관될 때마다 애플리케이션 서버 클래스 로더에서 볼 수 있습니다.

시작하기 전에

공유 라이브러리 설계 시 Java 기본 라이브러리 지원에 관한 다음 조건을 고려하십시오.
  • JVM(Java Virtual Machine)을 사용하면 하나의 클래스 로더만 특정 기본 라이브러리를 로드할 수 있습니다.
  • 클래스 로더에서 기본 라이브러리를 로드 해제하는 API(Application Programming Interface)가 없습니다.

    라이브러리를 찾은 클래스 로더가 가비지 콜렉션 중에 힙에서 수집될 때 기본 라이브러리는 JVM에 의해 로드 해제됩니다.

  • 기본 JVM 클래스 로더와는 달리, 애플리케이션 서버 클래스 로더는 현재 플랫폼의 기본 운영 체제 확장자를 사용하는 기본 공유 라이브러리만 로드합니다. 예를 들어, AIX에서는 애플리케이션 서버 클래스 로더에 의해 로드될 때 기본 공유 라이브러리가 .a로 끝나야 합니다. JVM 클래스 로더는 .a 또는 .so로 끝나는 파일을 로드합니다.

    [AIX]Java Web Start는 파일 확장자가 .so인 기본 공유 라이브러리만 로드할 수 있습니다. Java Web Start 배치를 위해 Java 아카이브(JAR) 파일에 패키징하기 전에 기본 공유 라이브러리가 .so 파일 확장자를 가지도록 이름을 바꾸십시오.

  • 애플리케이션 서버 클래스 로더는 애플리케이션 서버의 지속 기간 동안 지속됩니다.
  • 애플리케이션 클래스 로더는 애플리케이션이 중지되거나 동적으로 다시 로드될 때까지 지속됩니다.

    기본 라이브러리 경로를 사용하여 구성되는 공유 라이브러리가 애플리케이션과 연관되는 경우 애플리케이션이 다시 시작되거나 동적으로 다시 로드될 때마다 라이브러리가 이미 로드되어 있음을 표시하는 UnsatisfiedLinkError와 함께 애플리케이션이 실패할 수 있습니다. 애플리케이션 다시 시작 시 기본 라이브러리를 다시 로드하기 위해 공유 라이브러리 클래스를 호출하기 때문에 오류가 발생합니다. 그러나 기본 라이브러리를 이전에 로드한 애플리케이션 클래스 로더가 아직 가비지로 수집되지 않았기 때문에 기본 라이브러리는 여전히 메모리에 로드되어 있습니다.

  • JVM 클래스 로더만 종속 기본 라이브러리를 로드할 수 있습니다.

    예를 들어 NativeLib1NativeLib2에 종속적인 경우 NativeLib2는 JVM 클래스 로더에서 볼 수 있어야 합니다. NativeLib2를 포함하는 경로를 LIBPATH 환경 변수에서 정의한 Java 라이브러리 경로에 지정해야 합니다.

    [z/OS]LIBPATH(java.library.path) 특성은 process_name_region_libpath 환경 변수(예: control_region_libpath, server_region_libpath 또는 adjunct_region_libpath)를 사용하여 구성됩니다. 영역 LIBPATH 변수 설정 방법에 대한 지시사항은 BBOM0001I 메시지에서 참조된 변수 값 변경을 참조하십시오.

    공유 라이브러리에서 구성된 기본 라이브러리가 다른 기본 라이브러리에 종속적인 경우 라이브러리를 성공적으로 로드하려면 종속적인 라이브러리가 애플리케이션 서버를 호스트하는 JVM의 LIBPATH에 구성되어야 합니다.

이 태스크 정보

공유 라이브러리 설정 페이지에서 공유 라이브러리 구성 시 기본 라이브러리 경로의 값을 지정하면, 기본 라이브러리를 로드하는 동일한 클래스 로더에 의해 로드된 클래스 자체가 아닌 경우 이 경로에 있는 기본 라이브러리는 WebSphere® Application Server 애플리케이션 또는 공유 라이브러리 클래스 로더가 찾을 수 없습니다.

기본 라이브러리는 클래스 로더에 의해 두 번 이상 로드될 수 없기 때문에 애플리케이션 서버의 클래스 로더(이 클래스 로더는 서버의 지속 시간 동안 지속됨)와 연관된 공유 라이브러리 내에 기본 라이브러리가 로드되는 것이 좋습니다.

프로시저

  1. 기본 라이브러리를 로드하는 클래스에서 정적 메소드를 구현하십시오.

    기본 라이브러리를 로드하는 클래스에서 정적 블록에 있는 System.loadLibrary(native_library)를 호출하십시오. 예를 들어, 다음과 같습니다.

    static {System.loadLibrary("native_library");

    native_library는 클래스의 정적 초기화 중에 로드되고 이는 클래스 로드 시 딱 한 번만 발생합니다.

  2. 공유 라이브러리 설정 페이지에서 공유 라이브러리가 기본 라이브러리를 로드할 수 있게 하는 클래스 경로기본 라이브러리 경로의 값을 설정하십시오.

    공유 라이브러리를 애플리케이션 모듈과 연관시키려는 경우, 이 공유 라이브러리에 분리된 클래스 로더 사용도 선택하십시오. 이 설정을 사용 불가능하게 하는 경우, 공유 라이브러리를 애플리케이션 서버와 연관시키십시오.

  3. 공유 라이브러리를 연관시키십시오.
    • 이 공유 라이브러리에 분리된 클래스 로더 사용을 사용 불가능하게 한 경우, 공유 라이브러리를 애플리케이션 서버와 연관시키십시오.

      공유 라이브러리를 애플리케이션 대신 애플리케이션 서버의 클래스 로더와 연관시키면 서버의 애플리케이션이 다시 시작되거나 동적으로 다시 로드되더라도 공유 라이브러리가 애플리케이션 서버 클래스 로더에 의해 딱 한 번만 로드되도록 보장됩니다. 기본 라이브러리가 정적 블록 내에서 로드되기 때문에 기본 라이브러리는 두 번 이상 로드되지 않습니다.

    • 이 공유 라이브러리에 분리된 클래스 로더 사용을 사용 가능하게 한 경우, 공유 라이브러리를 애플리케이션 모듈과 연관시키십시오.

      분리된 공유 라이브러리 파일을 애플리케이션 또는 모듈과 연관시키면 해당 공유 라이브러리에 대해 작성된 개별 클래스 로더의 공유 라이브러리에서 나타내는 클래스를 로드합니다. 공유 라이브러리에 대한 개별 클래스 로더를 원하는 경우, 분리된 공유 라이브러리 파일을 서버와 연관시키지 마십시오. 공유 라이브러리를 서버와 연관시키는 경우, 제품은 분리 설정을 무시하고 공유 라이브러리에 있는 파일을 여전히 애플리케이션 서버 클래스 로더에 추가합니다. 즉, 분리된 공유 라이브러리 파일을 서버와 연관시키면 파일이 서버의 모든 애플리케이션과 연관됩니다.

      분리된 공유 라이브러리에 대해 작성된 클래스 로더는 다시 로드되지 않고 서버 클래스 로더와 같이 서버의 지속 시간 동안 존재합니다. 공유 기본 라이브러리의 경우, 분리된 공유 라이브러리를 사용하여 기본 라이브러리를 다시 로드할 때 오류가 발생하지 않도록 할 수 있습니다.

다음에 수행할 작업

애플리케이션이 공유 라이브러리를 사용할 수 있는지 확인하려면 애플리케이션을 테스트하거나 클래스 로더 뷰어에서 클래스 로더를 검사하십시오. 문제점 해결 > 클래스 로더 뷰어 > module_name > 테이블 보기를 클릭하십시오. 애플리케이션 모듈 클래스 로더의 클래스 경로에 공유 라이브러리가 사용하는 클래스가 나열됩니다.

주제 유형을 표시하는 아이콘 태스크 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tcws_sharedlib_nativelib
파일 이름:tcws_sharedlib_nativelib.html