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 절을 참조하십시오.
헤더 | 설명 | 필수사항인지 여부 |
---|---|---|
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 - 기능이 대체되지 않습니다.
추가 정보는 대체된 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"
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]"
자세한 정보는
독립 기능을 참조하십시오.- singleton. 이 지시문은 다음 값 중 하나를
사용합니다.
- True. 기능이 싱글톤입니다.
- False. 기능이 싱글톤이 아닙니다.
singleton 지시문은 선택사항입니다. 기본값은 False입니다.
이 지시문은 특정 기능이 싱글톤임을 선언하기 위해 사용됩니다. 싱글톤은 한 번에 제공된 기능 중 오직 하나의 버전만 런타임에 로드될 수 있음을 의미합니다. 기본적으로, 기능은 싱글톤이 아닙니다. 기능이 싱글톤이며 제공된 기능의 여러 버전이 서버 구성에 필요한 경우, 런타임은 필요한 모든 기능에서 허용하는 공통 버전을 찾으려고 시도합니다. 버전 허용에 대한 자세한 정보는 Subsystem-Content 아래의 ibm.tolerates 지시문을 참조하십시오.
기능이 싱글톤인 경우, 기호 이름 값은 "<singleton feature name >-<singleton version>" 양식입니다. 여기서 이름과 버전은 하이픈으로 분리됩니다. 싱글톤 기능 이름에는 하이픈이 포함될 수 있지만, 마지막 하이픈 이후의 문자는 싱글톤 버전으로 해석됩니다. 마지막 하이픈 이후의 문자가 유효한 버전이 아닌 경우, 싱글톤 버전 0.0.0이 사용되며 전체 기호 이름이 싱글톤 이름으로 사용됩니다. 싱글톤 버전은 Subsystem-Content 아래의 "ibm.tolerates" 지시문을 처리할 때 사용됩니다. 예를 들면 다음과 같습니다.Subsystem-SymbolicName: com.ibm.example.feature-1.0; visibility:=public; singleton:=true
Subsystem-Content
Subsystem-Content ::= content ( ',' content )*
content ::= unique-name ( ';' parameter )*
unique-name ::= unique-name (see OSGi core spec section 1.3.2)
- version - 번들을 찾을 때 일치시킬 버전의 범위. 이 범위에 있는 번들만 선택됩니다. 버전 범위의 일반적인 예는 [1,1.0.100)입니다.
- type - 공급할 컨텐츠의 유형.
컨텐츠 유형을 나타내는 임의의 값을 지정할 수 있습니다. 일부 유형의 경우
기능을 사용하는 서버의 OSGi 프레임워크에 번들이 설치되어 시작됩니다.
모든 유형은 기능이 포함된 설치 패키지에 컨텐츠가 포함되도록 합니다.
사전 정의된 값은
다음과 같습니다.
- osgi.bundle - 이 값은 기본값이며 서버의 OSGi 프레임워크와 설치 패키지 둘 다에 공급되어야 하는 OSGi 번들을 표시합니다.
- osgi.subsystem.feature - 이 값은 서버의 OSGi 프레임워크와 설치 패키지 둘 다에 기능이 제공되어야 함을 표시합니다. 이 기능은 Subsystem-SymbolicName 헤더에 지정된 이름을 사용해야 합니다.
- jar - 이 값은 설치 패키지에 JAR 파일이 포함되어야 하며 버전 범위, 위치 값 또는 둘을 조합하여 JAR 파일을 선택할 수 있음을 표시합니다.
- file - 이 값은 location 속성에 식별된 파일이 설치 패키지에 포함되어야 함을 나타냅니다.
- location - 번들의 위치. 번들 또는 JAR 유형의 경우,
이 값은 검색 경로를 나타내는 쉼표로 구분된 디렉토리 목록일 수 있습니다.
어떤 유형이든지 이 값은 자원을 직접 가리키는 단일 항목일 수 있으며,
파일 URL로 지정될 수 있습니다. 경로는 절대 경로 또는 상대 경로일 수 있습니다.
상대 경로는 기능이 포함된 제품 확장기능의 위치에 상대적인 위치로 분석됩니다.
사용자 기능의 경우 기본 제품 확장기능 위치인 ${wlp.user.dir}/extension이
사용됩니다. 기본값이 아닌 제품 확장기능의 위치는 ${wlp.install.dir}/etc/extensions
디렉토리에 있는 속성 파일의 com.ibm.websphere.productInstall 특성으로
선언됩니다. 예:
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 - 이 값은 애플리케이션이 시작될 때의 최신 단계를 나타냅니다.
- 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.1이 servlet-3.1이 존재하기 전에 작성되었으며 servlet-3.1이 추가되고 여기서 사용하는 기능에 의해 허용된 경우(sipServlet-1.1), featureC-1.1은 servlet-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.1이 servlet-3.1을 허용하는 데 동의하지 않아서 servlet-3.0이 있어야 하며 websocket-1.0이 servlet-3.0을 지원하지 않아서 servlet-3.1이 있어야 하기 때문에 보고됩니다.
솔루션은 featureC-1.1 역시 직접 servlet-3.0에 의존하며 servlet-3.1을 허용하는 것입니다.
- ibm.zos.extended.attributes - 연관된 파일의 확장된 속성을 지정된 값으로 설정합니다. 이 값은
'a', 'l', 'p' 및 's'의 조합이 될 수 있습니다. 값 옵션의 요약은 다음과 같습니다.
- a = APF 권한 부여됨
- p = 프로그램 제어됨
- s = 공유 주소 공간
- l = 공유 라이브러리
- ibm.file.encoding - 연관된 파일을 ASCII 인코딩에서 지정된 인코딩 유형으로 변환합니다. ibm.file.encoding 지시문은 값 "ebcdic"를 취할 수 있으며 이는 ASCII 인코딩된 파일은 EBCDIC 인코딩으로 변환합니다.
- 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 헤더에 제공된 서비스를 사용하려는 경우, 해당 서비스가 애플리케이션에 프로비저닝되기 위해서는 애플리케이션이 서비스에 대한 블루프린트 참조를 포함해야 합니다.
<?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 인터페이스나 기타 메커니즘(예: 선언 서비스(DS) 또는 Blueprint)을 사용하여 OSGi 서비스 레지스트리에 등록해야 합니다. 자세한 정보는 단순 활성화로 OSGi 번들 개발 및 OSGi 선언 서비스(DS)를 사용하여 고급 기능 작성의 내용을 참조하십시오.
IBM-SPI-Package
사용자 고유의 Liberty 기능을 작성할 경우 이 기능을 사용자 제품 확장기능에 설치합니다. 사용자 기능의 모든 패키지는 사용자 제품 확장기능에 설치되는 다른 모든 기능이 액세스할 수 있습니다. 하지만 사용자 기능의 패키지를 다른 제품 확장기능에 설치되는 기능이 액세스할 수 있도록 하려면 IBM-SPI-Package 헤더에 패키지 이름을 나열해야 합니다.
IBM-SPI-Package 헤더에 나열된 모든 패키지는 번들 Manifest 파일의 Export-Package 헤더에 나열하여 Liberty 기능의 번들로 내보내야 합니다.
IBM-ShortName
이 헤더는 server.xml 파일에서 기능을 지정하는 데 사용할 수 있는 기능의 약어입니다. Manifest 파일에 IBM-ShortName 헤더가 없으면 Subsystem-SymbolicName이 기본적으로 사용됩니다. IBM-ShortName 헤더는 공용 기능의 경우에만 올바릅니다.
IBM-AppliesTo
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
![[18.0.0.1 and later]](../ng_v18001plus.gif)
IBM-Maven-Dependency
IBM-Maven-Dependency: javax.servlet:javax.servlet-api:3.1.0
IBM-App-ForceRestart
- install - 기능이 설치되면 애플리케이션을 다시 시작합니다.
- uninstall - 기능이 설치 제거되면 애플리케이션을 다시 시작합니다.
- install,uninstall - 기능이 설치되거나 설치 제거되면 애플리케이션을 다시 시작합니다.
기능 Manifest 파일의 예
<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.utils 및
com.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