Liberty 기능 Manifest 파일

Liberty 기능은 기능 Manifest 파일로 구성되며 Liberty 런타임 환경에서 특정 기능에 해당하는 클래스와 서비스를 제공하는 하나 이상의 OSGi 번들 콜렉션입니다. 기능 Manifest의 형식과 Manifest 파일의 각 헤더의 의미를 볼 수 있습니다.

Liberty의 기능 Manifest 파일은 OSGi Enterprise R5 스펙의 서브시스템 서비스 메타데이터 형식을 사용합니다. 기능은 lib/features 디렉토리에 저장된 기능 Manifest 파일(.mf 파일)에 의해 정의되며, 서브시스템의 사용자 정의 유형을 사용해야 합니다(osgi.subsystem.feature). OSGi Manifest 구문에 대한 자세한 정보는 OSGi 코어 스펙의 1.3.2 절을 참조하십시오.

참고: 기능 Manifest 파일에서 속성의 양식은 name=value이지만 지시문의 양식은 name:=value입니다.

다음 헤더가 정의되어 있습니다.
표 1. 기능 Manifest 파일의 헤더.

다음 표는 Liberty에서 기능 Manifest 파일의 헤더를 보여줍니다. 첫 번째 열은 헤더 목록을 표시하고, 두 번째 열은 각 헤더의 설명을 표시하며, 세 번째 열은 헤더가 필요한지 여부를 나타냅니다.

헤더 설명 필수 여부
Subsystem-ManifestVersion 기능 Manifest 파일의 버전 형식. 1로 설정해야 합니다. 아니오
Subsystem-SymbolicName 기능 및 모든 속성이나 지시문의 기호 이름
Subsystem-Version 기능의 버전. 기능 버전 정의 방식에 대한 자세한 정보는 OSGi 코어 스펙 절 3.2.5를 참조하십시오. 아니오
Subsystem-Type 기능의 서브시스템 유형. 모든 기능은 현재 동일한 서브시스템의 유형입니다(osgi.subsystem.feature).
Subsystem-Content 기능의 서브시스템 컨텐츠. 이 기능을 실행하는 데 필요한 번들 및 서브시스템의 쉼표로 구분된 목록입니다. server.xml 파일에서 자동 기능을 구성하려면 필요한 기능을 포함하는 기능 헤더를 가지고 있고 이러한 기능이 서브시스템 컨텐츠에 정의되어 있어야 합니다.
Subsystem-Localization 기능의 자국어 지원 파일이 있는 위치입니다. 아니오
Subsystem-Name 사람이 판독할 수 있는 축약된 기능 이름입니다. 이 값은 현지화할 수 있습니다. 아니오
Subsystem-Description 기능의 설명입니다. 이 값은 현지화할 수 있습니다. 아니오
IBM-Feature-Version 이 서브시스템 유형의 버전. 2로 설정해야 합니다.
IBM-Provision-Capability 기능을 자동으로 제공할 수 있는지 여부를 나타내는 기능 헤더. 아니오
IBM-API-Package 이 기능에 의해 애플리케이션에 노출되는 API 패키지, 다른 제품 확장기능의 기능, Liberty 커널. 아니오
IBM-API-Service 이 기능이 OSGi 애플리케이션에 표시하는 OSGi 서비스 아니오
IBM-SPI-Package 다른 제품 확장기능의 기능에 대해 이 기능에 의해 노출되는 SPI 패키지와, Liberty 커널. 아니오
IBM-ShortName 기능의 축약 이름입니다. 아니오
IBM-AppliesTo 이 기능이 적용되는 Liberty 버전입니다. 아니오
Subsystem-License 이 기능의 라이센스 유형입니다. 아니오
IBM-License-Agreement 라이센스 계약 파일의 위치 접두부입니다. 아니오
IBM-License-Information 라이센스 정보 파일의 위치 접두부입니다. 아니오
IBM-App-ForceRestart 실행 중인 서버에 기능을 설치하거나 설치 제거할 때 애플리케이션이 다시 시작되도록 지정합니다. 아니오

Subsystem-SymbolicName

이 헤더의 구문은 번들의 Bundle-SymbolicName 구문과 일치합니다. 패키지 이름 스타일의 구문을 따르는 기호 이름을 가지고 있으며 선택적으로 일련의 속성 및 지시문을 사용할 수 있습니다.

다음과 같은 속성이 지원됩니다.
  • superseded. 이 속성은 이 기능이 하나 이상의 기능이나 기능 항목으로 대체되는지 여부를 나타냅니다. 다음 값 중 하나를 사용합니다.
    • true - 기능이 대체됩니다.
    • false - 기능이 대체되지 않습니다.
    이 속성은 선택사항이며 기본값은 false입니다.

    자세한 정보는 대체되는 Liberty 기능의 내용을 참조하십시오.

  • superseded-by. 이 속성은 선택사항이며 이 기능을 대체하는 기능(있는 경우)의 쉼표로 구분된 목록을 지정합니다.
다음 지시문이 지원됩니다.
  • visibility. 이 지시문은 다음 값 중 하나를 사용합니다.
    • public - API로 간주되는 기능. 기능은 server.xml 파일에서의 사용에 대해 개발자 도구에 의해 지원되고 메시지에서 출력됩니다.
    • protected - SPI로 간주되는 기능. 기능은 server.xml 파일에서의 사용에 대해 개발자 도구에 의해 지원되지 않거나 메시지에서 출력됩니다. 기능은 익스텐더가 상위 레벨 기능을 빌드하는 데 사용할 수 있도록 제공됩니다.
    • private - (기본값) 기능은 제품 내부에서 사용됩니다. 기능은 server.xml 파일에서의 사용에 대해 지원되지 않거나 익스텐더 기능에 의해 참조되지 않습니다. 기능은 언제든지(수정팩 사이를 포함하여) 변경할 수 있습니다.
예를 들어 다음과 같습니다.
Subsystem-SymbolicName: com.ibm.example.feature-1.0; 
    visibility:=public; superseded=true; superseded-by="com.ibm.example.feature-2.0"
대체(superseded-by) 목록에 있는 기능 이름이 대괄호([])로 묶인 경우 이 기능은 대체하는 기능과 구분되어 있습니다. 다음 예제에서 servlet-3.0ldapRegistry-3.0 기능을 포함하고 있는 appSecurity-1.0 기능이 servlet-3.0ldapRegistry-3.0 기능을 포함하지 않는 appSecurity-2.0 기능으로 대체됩니다.
IBM-ShortName: appSecurity-1.0
Subsystem-SymbolicName: com.ibm.websphere.appserver.appSecurity-1.0; visibility:=public;
superseded=true; superseded-by="appSecurity-2.0, [servlet-3.0], [ldapRegistry-3.0]"
자세한 정보는 독립 기능을 참조하십시오.
우수 사례: 개발자 도구가 기능을 표시해야 하면 public이어야 합니다. 신뢰 당사자에게만 기능을 제공하는 경우에는 protected여야 합니다. 기능이 내부용이고 언제든지 변경할 수 있는 경우에는 private이어야 합니다.
  • singleton. 이 지시문은 다음 값 중 하나를 사용합니다.
    • True. 기능이 싱글톤입니다.
    • False. 기능이 싱글톤이 아닙니다.

    singleton 지시문은 선택사항입니다. 기본값은 False입니다.

    이 지시문은 특정 기능이 싱글톤임을 선언하기 위해 사용됩니다. 싱글톤은 한 번에 제공된 기능 중 오직 하나의 버전만 런타임에 로드될 수 있음을 의미합니다. 기본적으로, 기능은 싱글톤이 아닙니다. 기능이 싱글톤이며 제공된 기능의 여러 버전이 서버 구성에서 필요한 경우, 런타임은 모든 필수 기능에 의해 허용되는 공통 버전을 찾으려고 시도합니다. 버전 허용에 대한 자세한 정보는 Subsystem-Content 아래의 ibm.tolerates 지시문을 참조하십시오.

    기능이 싱글톤인 경우 기호 이름 값은 "<싱글톤 기능 이름>-<싱글톤 버전>" 양식입니다. 여기서 이름과 버전은 하이픈으로 분리됩니다. 싱글톤 기능 이름에는 하이픈이 포함될 수 있지만, 마지막 하이픈 이후의 문자는 싱글톤 버전으로 해석됩니다. 마지막 하이픈 이후의 문자가 유효한 버전이 아닌 경우, 싱글톤 버전 0.0.0이 사용되며 전체 기호 이름이 싱글톤 이름으로 사용됩니다. 싱글톤 버전은 Subsystem-Content 아래의 "ibm.tolerates" 지시문을 처리할 때 사용됩니다. 예를 들면, 다음과 같습니다.
    Subsystem-SymbolicName: com.ibm.example.feature-1.0; 
        visibility:=public; singleton:=true

Subsystem-Content

이 헤더는 런타임 및 설치를 위한 기능의 컨텐츠를 정의합니다. 다음과 같은 구문이 있는 Subsystem 스펙과 동일한 헤더 구문을 사용합니다.
Subsystem-Content ::= content ( ',' content )*
        content ::= unique-name ( ';' parameter )*
        unique-name ::= unique-name        (see OSGi core spec section 1.3.2)
unique-nameBundle-SymbolicName 또는 Subsystem-SymbolicName 헤더의 양식을 사용합니다. 다음과 같은 속성이 지원됩니다.
  • version - 번들을 찾을 때 일치시킬 버전의 범위. 이 범위에 있는 번들만 선택됩니다. 버전 범위의 일반적인 예는 [1,1.0.100)입니다.
  • type - 공급할 컨텐츠의 유형. 컨텐츠 유형을 표시할 임의의 값을 지정할 수 있습니다. 일부 유형은 기능을 사용하는 서버의 OSGi 프레임워크에 번들이 설치되어 시작되도록 합니다. 모든 유형은 기능이 포함된 설치 패키지에 컨텐츠가 포함되도록 합니다. 사전 정의된 값은 다음과 같습니다.
    • osgi.bundle - 이 값은 기본값이며 서버의 OSGi 프레임워크와 설치 패키지 둘 다에 공급되어야 하는 OSGi 번들을 표시합니다.
    • osgi.subsystem.feature - 이 값은 서버의 OSGi 프레임워크와 설치 패키지 둘 다에 기능이 제공되어야 함을 표시합니다. 이 기능은 Subsystem-SymbolicName 헤더에 지정된 이름을 사용해야 합니다.
    • jar - 이 값은 설치 패키지에 JAR 파일이 포함되어야 하며 버전 범위, 위치 값 또는 둘을 조합하여 JAR 파일을 선택할 수 있음을 표시합니다.
    • file - 이 값은 location 속성에 식별된 파일이 설치 패키지에 포함되어야 함을 표시합니다.
다음 지시문이 지원됩니다.
  • location - 번들의 위치. 번들 또는 JAR 유형의 경우, 이 값은 dev 디렉토리의 스펙 및 API 번들을 식별하는 데 사용되는 디렉토리의 쉼표로 구분된 목록이나 JAR 파일을 직접 가리키는 단일 항목일 수 있습니다. typefile인 경우, 단일 항목만 허용되며 해당 파일을 직접 가리켜야 합니다.
    예:
    Subsystem-Content: com.ibm.websphere.appserver.api.basics; version="[1,1.0.100)"; type=jar; location:="dev/api/ibm/,lib/",
                       com.ibm.websphere.appserver.spi.application; 
    				   				   location:="dev/spi/ibm/com.ibm.websphere.appserver.spi.application_1.0.0.jar"; type="jar",
                       com.ibm.websphere.appserver.spi.application_1.0.0-javadoc.zip;
    				   				   location:="dev/spi/ibm/javadoc/com.ibm.websphere.appserver.spi.application_1.0.0-javadoc.zip"; type="file"
  • start-phase - 시스템 시작 중에 번들을 시작해야 할 때의 시작 단계(Phase). start-phase 지시문은 다음 값 중 하나를 사용할 수 있습니다.
    • SERVICE - 이 값은 초기 단계를 나타냅니다. 기본적으로 시작 레벨인 9로 맵핑됩니다.
    • CONTAINER - start-phase가 제공되지 않는 경우 기본값입니다. 애플리케이션 컨테이너가 시작될 때의 컨테이너 단계를 나타냅니다. 기본적으로 시작 레벨인 12로 맵핑됩니다.
    • APPLICATION - 이 값은 애플리케이션이 시작될 때의 최신 단계를 나타냅니다.
    _LATE를 추가하여 이러한 구문 바로 앞이나 바로 뒤에서 시작하도록 번들을 정의하거나 _EARLY를 추가하여 주요 구문 앞에 정의할 수 있습니다. 컨테이너 구문 바로 다음에 실행하려면 CONTAINER_LATE를 사용하고 APPLICATION 구문 이전에 실행하려면 APPLICATION_EARLY를 사용하십시오.
  • ibm.tolerates - 버전 충돌이 있는 경우 시스템으로 프로비저닝되는 싱글톤 기능(type=osgi.subsystem.feature)의 버전 또는 대체 싱글톤 버전을 지정합니다.

    unique-name은 싱글톤 기능의 선호 버전의 기호 이름을 지정합니다. 포함된 기능이 제공된 싱글톤 기능의 기타 싱글톤 버전과 함께 작동한다고 알려진 경우, 이 싱글톤 버전은 ibm.tolerates 지시문을 사용하여 지정될 수 있습니다. 이는 기타 기능이 제공된 싱글톤 기능의 충돌 중인 필수 버전 값을 정의하는 경우에 정의 기능에 대해 훨씬 많은 호환성을 제공합니다.

    ibm.tolerates 지시문에 나열된 싱글톤 버전은 버전 충돌의 경우에만 사용됩니다. ibm.tolerates 지시문에 나열된 버전의 순서는 중요하지 않습니다. ibm.tolerates 지시문에 나열된 버전은 종속성 요구사항을 충족시키기 위해 선택될 수 있습니다.

    제공된 싱글톤 기능의 버전 또는 허용된 버전은 ibm.tolerates 지시문에 명시적으로 나열되어야 합니다. 허용되는 버전의 목록을 구분하려면 쉼표를 사용하십시오. 버전 범위의 지정은 지원되지 않습니다.

    예:
    Subsystem-Content: com.ibm.websphere.appserver.example.featureA-1.1; ibm.tolerates:="1.2"; type="osgi.subsystem.feature",
                       com.ibm.websphere.appserver.example.featureB-1.1; ibm.tolerates:="1.2, 1.4, 1.6"; type="osgi.subsystem.feature"
    참고:

    허용된 버전은 임시 버전이 아닙니다. 이는 사용자 기능이 의존하는 기능이 테스트를 거치지 않은 상태에서 기능의 후속 레벨 지원을 자동 선택하지 못하도록 방지합니다.

    예: 사용자 기능 featureC-1.1에는 자체 Manifest 파일의 Subsystem-Content 헤더에 sipServlet-1.1이 포함되어 있습니다. sipServlet-1.1에는 servlet-3.0이 포함되며 servlet 3.1을 허용합니다. featureC-1.1servlet-3.1이 존재하기 전에 작성되었으며 servlet-3.1이 추가되고 여기서 사용하는 기능에 의해 허용된 경우(sipServlet-1.1), featureC-1.1servlet-3.1도 역시 허용했는지 여부에 대해 언급해야 합니다.

    다음 두 기능을 갖도록 server.xml 파일을 구성하는 경우:
    <feature>usr:featureC-1.1</feature> // includes: sipServlet-1.1
    <feature>websocket-1.0</feature> // this feature requires servlet-3.1
    다음과 유사한 오류 메시지가 표시됨을 보게 됩니다.
    CWWKF0033E: The singleton features servlet-3.0 and servlet-3.1 cannot be loaded at the same time. 
    The configured features usr:featureC-1.1 and websocket-1.0 include one or more features that cause the conflict. 
    Your configuration is not supported; update server.xml to remove incompatible features."

    이 오류는 featureC-1.1servlet-3.1을 허용하는 데 동의하지 않아서 servlet-3.0이 있어야 하며 websocket-1.0servlet-3.0을 지원하지 않아서 servlet-3.1이 있어야 하기 때문에 보고됩니다.

    솔루션은 featureC-1.1 역시 직접 servlet-3.0에 의존하며 servlet-3.1을 허용하는 것입니다.

AIX 플랫폼용HP UNIX 플랫폼용LINUX 플랫폼용Solaris 플랫폼용IBM i 플랫폼용다음 지시문이 지원됩니다.
  • ibm.executable - 값이 "true"로 설정된 경우 현재 umask 설정에 따라 연관된 파일에 실행 권한을 추가합니다. 그 외의 값인 경우에는 조치가 수행되지 않습니다. 다음 표에는 현재 umask 및 실행 권한을 얻는 클래스가 표시되어 있습니다.
    표 2. umask 값, 그리고 ibm.executable로 실행 권한이 설정되는 클래스의 예제
    Umask 클래스에 부여되는 실행 권한
    022 소유자, 그룹, 기타
    023 소유자, 그룹
    055 소유자

Subsystem-Localization

이 헤더는 기능의 자국어 지원 파일 위치를 지정합니다.

예를 들어 다음과 같습니다.
Subsystem-Localization: OSGI-INF/l10n/loc

Subsystem-Name

이 헤더를 사용하여 사람이 판독할 수 있는 축약된 기능 이름을 제공하십시오. 리터럴 문자열 또는 특성 이름을 지정할 수 있습니다. 특성 이름을 지정하는 경우, 값을 현지화할 수 있습니다.

예:
Subsystem-Name: %name
여기서 name의 값은 다음 형식으로 Subsystem-Localization 헤더(이전 예에서는 loc.properties)에서 지정한 위치의 특성 파일에 정의됩니다.
name=feature_name

Subsystem-Description

이 헤더를 사용하여 기능의 설명을 제공하십시오. 리터럴 문자열 또는 특성 이름을 지정할 수 있습니다. 특성 이름을 지정하는 경우, 값을 현지화할 수 있습니다.

예:
Subsystem-Description: %desc
여기서 desc의 값은 다음 형식으로 Subsystem-Localization 헤더(이전 예에서는 loc.properties)에서 지정한 위치의 특성 파일에 정의됩니다.
desc=feature_description

IBM-Provision-Capability

자동으로 프로비저닝되는 기능은 Manifest에 IBM-Provision-Capability 헤더가 있는 기능입니다. 이 헤더는 이 기능이 자동으로 프로비저닝되기 위해 프로비저닝되어야 하는 다른 기능을 설명합니다. 다른 기능을 나열할 때는 기능의 Subsystem-SymbolicName 헤더를 사용하십시오. 임의의 기능이 server.xml 파일에서 구성될 때, runtime은 모든 자동으로 프로비저닝된 기능이 기능을 충족했는지 여부 및 충족한 경우 자동으로 프로비저닝되는지 여부를 검사합니다.

IBM-Provision-Capability 헤더의 형식은 표준 OSGi LDAP 필터를 사용합니다.

IBM-API-Package

이 헤더는 애플리케이션에 표시되는 API 패키지를 표시하는 데 사용됩니다. Export-Package 헤더 구문과 일치합니다. 즉, 쉼표로 구분된 API 패키지 목록이지만, API 패키지 각각에는 몇 가지 속성이 있을 수 있습니다.

다음 속성이 지원됩니다.
  • type - API 패키지의 유형. type 속성은 다음 값 중 하나를 사용합니다.
    • spec - 표준 본문에서 제공하는 API를 나타냅니다(예: javax.servlet 또는 org.osgi.framework).
    • ibm-api - IBM®에서 제공하는 부가가치 API를 표시합니다.
    • api - 사용자 정의 API를 표시합니다. 이것이 기본값입니다.
    • third-party - 가시적이지만 IBM에서 제어하지 않습니다. 일반적으로 이것이 개방형 소스 패키지입니다.
    • internal - 작동하려면 애플리케이션에 노출해야 하는 비API 패키지를 표시합니다. Java™ 코드가 개선되거나 악화된 바이트코드인 경우 런타임 시 이를 사용하여 내부 코드에 참조를 추가할 수 있습니다.
예:
IBM-API-Package: javax.servlet; type="spec",
                 com.ibm.websphere.servlet.session; type="ibm-api",
                 com.ibm.wsspi.webcontainer.annotation; type="internal"

IBM-API-Service

이 헤더는 OSGi 애플리케이션에 표시되는 기능의 서비스를 나타내는 데 사용됩니다. 기능은 또한 OSGi 서비스 레지스트리에서 서비스를 등록해야 합니다.

다음 구문을 사용합니다.
IBM-API-Service ::= service ( ',' service )*
                    service ::= service-name ( ';' attribute )*
                    service-name ::= unique-name
service-name은 서비스의 Java 클래스나 인터페이스 이름입니다. 속성은 서비스에 대한 서비스 특성으로 해석됩니다.
예:
IBM-API-Service: com.ibm.example.service.FeatureServiceOne; 
                 myServiceAttribute=myAttributeValue,
                 com.ibm.example.service.FeatureServiceTwo

OSGi 애플리케이션이 IBM-API-Service 헤더에 의해 제공되는 서비스를 사용하려는 경우, 해당 서비스가 애플리케이션에 프로비저닝되기 위해 애플리케이션이 서비스에 대한 blueprint 참조를 포함해야 합니다.

예:
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
		<reference id="FeatureServiceOneRef"
						interface="com.ibm.example.service.FeatureServiceOne" />
</blueprint>

OSGi 애플리케이션의 번들이 서비스를 사용할 수 있기 위해서는 인터페이스 패키지가 해당 번들에 사용 가능해야 하며, 이것은 인터페이스 패키지가 이용 번들의 Manifest 파일에 있는 Import-Package 헤더에서 지정되어야 함을 의미합니다. 인터페이스 패키지는 또한 기능 번들의 Export-Package 헤더에서 지정되고 기능 Manifest 파일의 IBM-API-Package 헤더에서 지정되어야 합니다. 기능이 제공하는 서비스는 OSGi BundleContext 인터페이스나 기타 메커니즘(예: Declarative Services 또는 Blueprint)을 사용하여 OSGi 서비스 레지스트리에 등록되어야 합니다. 자세한 정보는 단순 활성화로 OSGi 번들 개발OSGi Declarative Services를 사용하여 고급 기능 작성의 내용을 참조하십시오.

IBM-SPI-Package

사용자 고유의 Liberty 기능을 작성할 경우 이 기능을 사용자 제품 확장기능에 설치합니다. 사용자 기능의 모든 패키지는 사용자 제품 확장기능에 설치되는 다른 모든 기능이 액세스할 수 있습니다. 하지만 사용자 기능의 패키지를 다른 제품 확장기능에 설치되는 기능이 액세스할 수 있도록 하려면 IBM-SPI-Package 헤더에 패키지 이름을 나열해야 합니다.

번들 Manifest 파일의 Export-Package 헤더에 나열하여 IBM-SPI-Package 헤더에 나열된 모든 패키지를 Liberty 기능의 번들로 내보내야 합니다.

IBM-ShortName

이 헤더는 server.xml 파일에서 기능을 지정하는 데 사용할 수 있는 기능의 약어입니다. Manifest 파일에 IBM-ShortName 헤더가 없으면 Subsystem-SymbolicName이 기본적으로 사용됩니다. IBM-ShortName 헤더는 공용 기능의 경우에만 올바릅니다.

IBM-AppliesTo

이 헤더는 이 기능이 적용되는 Liberty 버전을 지정합니다. 각각 다음 형식으로 된 항목의 목록을 쉼표로 구분하여 제공하십시오.
product_id; productVersion=product_version; productInstallType=product_install_type; productEdition=product_editions

두 개 이상의 항목을 제공하는 경우 product_id의 값은 각각 서로 달라야 합니다.

productVersion 값은 정확한 버전(예: 8.5.5.7)이거나 더하기 부호(+)로 끝나는 버전으로 표시된 최소 버전(예: 8.5.5.7+)일 수 있습니다.

productEdition의 값은 단일 에디션 또는 따옴표로 묶은 쉼표로 구분된 에디션의 목록일 수 있습니다.

예:
IBM-AppliesTo: com.ibm.websphere.appserver; productVersion=8.5.5.6; productInstallType=Archive; productEdition="BASE,DEVELOPERS,ND"

Subsystem-License

이 헤더는 이 기능의 라이센스 유형을 정의합니다. Subsystem-License 헤더의 값을 제공하고 IBM-License-Agreement 및 IBM-License-Information 헤더의 값을 제공하지 않으면 설치 중에 라이센스에 동의하도록 Subsystem-License 헤더 값이 표시됩니다.

동일한 Subsystem-License 헤더 값으로 기능이 이미 설치된 경우 설치 중에 라이센스가 표시되지 않으며 라이센스에 동의하도록 요청하지 않습니다. Subsystem-Content 헤더의 종속성이 Subsystem-License 헤더 값이 동일한 두 개 이상의 기능을 설치 중임을 의미하는 경우, 설치 중에 라이센스에 한 번만 동의하면 됩니다.

예:
Subsystem-License: L-JTHS-93TMHH
Subsystem-License: http://www.apache.org/licenses/LICENSE-2.0.html

IBM-License-Agreement

이 헤더는 라이센스 계약 파일의 위치 접두부를 지정합니다. 서브시스템 아카이브의 파일 경로를 LA_language 파일에 제공하십시오. 이 때, "_"는 포함하지 않고 "_" 바로 앞까지만 제공하십시오(언어 코드는 설치 도구에서 자동으로 추가함). 이 라이센스에 동의하지 않으면 기능을 설치할 때 라이센스에 동의해야 합니다. 라이센스 파일은 Liberty 설치 디렉토리에 복사됩니다.

예:
IBM-License-Agreement: lafiles/LA

IBM-License-Information

이 헤더는 라이센스 정보 파일의 위치 접두부를 지정합니다. 서브시스템 아카이브의 파일 경로를 LI_language 파일에 제공하십시오. 이 때, "_"는 포함하지 않고 "_" 바로 앞까지만 제공하십시오(언어 코드는 설치 도구에서 자동으로 추가함). 이 라이센스에 동의하지 않으면 기능을 설치할 때 라이센스에 동의해야 합니다. 라이센스 파일은 Liberty 설치 디렉토리에 복사됩니다.

예:
IBM-License-Information: lafiles/LI

IBM-App-ForceRestart

이 헤더를 사용하면 실행 중인 서버에 기능을 설치하거나 제거할 때 애플리케이션이 다시 시작됩니다. 이 헤더는 다음 값 중 하나를 사용할 수 있습니다.
  • install - 기능이 설치되면 애플리케이션을 다시 시작합니다.
  • uninstall - 기능이 설치 제거되면 애플리케이션을 다시 시작합니다.
  • install,uninstall - 기능이 설치되거나 설치 제거되면 애플리케이션을 다시 시작합니다.

기능 Manifest 파일의 예

다음 예제는 example-1.0 기능에 대한 정의를 보여줍니다. 공용 가시성 속성은 이 기능이 직접 서버 구성(server.xml) 파일에 지정될 수 있도록 허용합니다. 또한 이 속성은 개발자 도구의 서버 구성 보기에 표시되는 기능의 드롭 다운 목록에 포함되고, 다른 제품 확장기능에 있는 기능의 포함에 사용 가능하게 됩니다. 이 기능이 런타임 설치의 usr 제품 확장기능에 설치되는 경우 이 기능은 다음 코드를 server.xml 파일에 포함하여 서버에 구성될 수 있습니다.
<featureManager>
		<feature>usr:example-1.0</feature>
</featureManager>
서버에 이 기능을 구성하면 지정된 번들(com.ibm.example.bundle1)이 서버 런타임 환경의 OSGi 프레임워크에 설치되어 시작됩니다. 단일 API 패키지(com.ibm.example.publicapi)는 해당 서버의 모든 애플리케이션에 가시적입니다. api 패키지 유형에 대한 가시성을 갖지 않도록 구성되는 Java EE 애플리케이션의 경우에는 예외입니다. OSGi 애플리케이션은 패키지를 사용하려는 경우 명시적으로 이 패키지를 가져와야 합니다. 두 개의 SPI 패키지(com.ibm.example.spi.utilscom.acme.spi.spiservices)는 서버에 있는 모든 기능 코드에 가시적입니다. API 패키지에도 그럴 것입니다.
IBM-Feature-Version: 2
Subsystem-ManifestVersion: 1.0
Subsystem-SymbolicName: com.ibm.example-1.0; visibility:=public
Subsystem-Version: 1.0.0.qualifier
Subsystem-Type: osgi.subsystem.feature
Subsystem-Content: com.ibm.example.bundle1; version="1.0.0"
Subsystem-Localization: OSGI-INF/l10n/loc
Manifest-Version: 1.0
Subsystem-Name: %name
Subsystem-Description: %desc
IBM-API-Package: com.ibm.example.publicapi; type="api"
IBM-SPI-Package: com.ibm.example.spi.utils, com.ibm.example.spi.spiservices
IBM-ShortName: example-1.0

주제의 유형을 표시하는 아이콘 참조 주제



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