Karaf User Guide - 프로비저닝

[원문 출처] http://karaf.apache.org/manual/latest-2.3.x/users-guide/provisioning.html

Provisioning (프로비저닝)

Karaf provides a simple, yet flexible, way to provision applications or "features". Such a mechanism is mainly provided by a set of commands available in the features shell. The provisioning system uses xml "repositories" that define a set of features.
Karaf 는 단순하고 유연한 어플리케이션을 프로비저닝 하는 방법을 또는 기능을 제공한다. 그런 메카니즘은 주로features 쉘에서 가능한 명령어 세트에 의해서 제공된다. 프로비너징 시스템은 기능 세트가 정의된  xml "저장소" 를 사용한다. 

Repositories (저장소)

The complete xml schema for feature descriptor are available on Features XML Schema page. We recommend using this XML schema. It will allow Karaf to validate your repository before parsing. You may also verify your descriptor before adding it to Karaf by simply validation, even from IDE level.
기능 서술자를 위한 완전한 xml 스키마는 Features XML Schema 페이지에서  사용할 수 있다. 우리는 이 XML 스키마를 사용 하는 것을 추천한다. 그것은  karaf가 파싱하기 전에 당신의 저장소가 유효하게 허용하게 될 것이다. 당신은 또한 Karaf에 단순한 검증에 의해서 심지어 IDE 레벨에서 그것을 추가 하기 전에 서술자를 입증할지 모른다.

Here is an example of such a repository:
여기 그런 저장소의 예제이다.

<features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0">
    <feature name="spring" version="3.0.4.RELEASE">
        <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.aopalliance/1.0_1</bundle>
        <bundle>mvn:org.springframework/spring-core/3.0.4.RELEASE</bundle>
        <bundle>mvn:org.springframework/spring-beans/3.0.4.RELEASE</bundle>
        <bundle>mvn:org.springframework/spring-aop/3.0.4.RELEASE</bundle>
        <bundle>mvn:org.springframework/spring-context/3.0.4.RELEASE</bundle>
        <bundle>mvn:org.springframework/spring-context-support/3.0.4.RELEASE</bundle>
    </feature>
</features>

A repository includes a list of feature elements, each one representing an application that can be installed. The feature is identified by its name which must be unique amongst all the repositories used and consists of a set of bundles that need to be installed along with some optional dependencies on other features and some optional configurations for the Configuration Admin OSGi service.
저장소는feature  엘리먼트를 포함하고 각각의 어플리케이션이 나타내고 있는 것이 설치 될 수 있다. 이 기능은 모든 저장소를 사용하고 다른 기능에 대한 몇 가지 옵션 종속성과 구성 관리 OSGi 서비스에 대한 일부 옵션 구성을 함께 설치 될 필요가 있는 번들 세트로 구성되고 사용되어지는 모든 저장소들 사이에서 유일 해야하는 그 이름으로 식별됩니다.

References to features define in other repositories are allow and can be achieved by adding a list of repository.
다른 저장소에서 정의된 기능에 대한 참조는 자장소에 목록을 추가 함으로써 허용하고 도달할 수 있다.

<features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0">
  <repository>mvn:org.apache.servicemix.nmr/apache-servicemix-nmr/1.3.0/xml/features</repository>
  <repository>mvn:org.apache.camel.karaf/apache-camel/2.5.0/xml/features</repository>
  <repository>mvn:org.apache.karaf/apache-karaf/2.1.2/xml/features</repository>
  ...

Be careful when you define them as there is a risk of 'cycling' dependencies.
당신이 순환 의존관게의 리스크로써 그것을 정의 할때 주의하라

Remark: By default, all the features defined in a repository are not installed at the launch of Apache Karaf (see section here after 'h2. Service configuration' for more info).
기본적으로 저장소에 정의된 모든 기능들은 Apache Karaf 의 런처에 설치되어 있는 것은 아니다. (여기 뒤에 'h2 서비스 환경 구성' 더 많은 정보를 봐라)

Bundles (번들)

The main information provided by a feature is the set of OSGi bundles that defines the application. Such bundles are URLs pointing to the actual bundle jars. For example, one would write the following definition:
기능에 의해 제공되는 이 주요 정보는 어플리케이션을 정의하는 OSGi 번들의 세트이다. 그런 번들들은 실제 번들의 jar 들을 가리키는 URL들이다. 예를 들면 하나는 다음 정의를기록할 것이다.

<bundle>http://repo1.maven.org/maven2/org/apache/servicemix/nmr/org.apache.servicemix.nmr.api/1.0.0-m2/org.apache.servicemix.nmr.api-1.0.0-m2.jar</bundle>

Doing this will make sure the above bundle is installed while installing the feature.
기능을 설치 하는 동안 위의 번들이 설치되어 있는 것이 확인 하게 할 것이다.

However, Karaf provides several URL handlers, in addition to the usual ones (file, http, etc...). One of these is the Maven URL handler, which allow reusing Maven repositories to point to the bundles.
그러나 Karaf는 보통 하용하는 것들(file, http, etc...)에 추가로  몇몇 URL 핸들러들을 제공한다. 그것들 중에 하나는 번들 가리키기 위한 Maven 저장소들을 재 하용 하는 것을 허용하는 Maven URL 핸들러이다.

Maven URL Handler (Maven URL 핸들러)

The equivalent of the above bundle would be:
위 번들의 상응하는 것은 

<bundle>mvn:org.apache.servicemix.nmr/org.apache.servicemix.nmr.api/1.0.0-m2</bundle>

In addition to being less verbose, the Maven url handlers can also resolve snapshots and can use a local copy of the jar if one is available in your Maven local repository.
덜 자세하게 되는것 이외에도 Maven URL 핸들러들은 또한  스냅샷을 해결 할 수 있고 만약 그것이 당신의 Maven 로컬 저장소서 사용 가능 하면 그 jar의 로컬 사본을 사용 할 수 있다. 

The org.ops4j.pax.url.mvn bundle resolves mvn URLs. This flexible tool can be configured through the configuration service. For example, to find the current repositories type:
org.ops4j.pax.url.mvn 번들은 mvn  URL들을 해결한다.  유연한 툴은 환경 구성 서비스를 통해서 환경구성 될 수 있다. 예로 현재 저장소 유형을 찾기기 위해

karaf@root:/> config:list
...
----------------------------------------------------------------
Pid:            org.ops4j.pax.url.mvn
BundleLocation: mvn:org.ops4j.pax.url/pax-url-mvn/0.3.3
Properties:
   service.pid = org.ops4j.pax.url.mvn
   org.ops4j.pax.url.mvn.defaultRepositories = file:/opt/development/karaf/assembly/target/apache-felix-karaf-1.2.0-SNAPSHOT/system@snapshots
   org.ops4j.pax.url.mvn.repositories = http://repo1.maven.org/maven2, 
                                         http://svn.apache.org/repos/asf/servicemix/m2-repo 
   below = list of repositories and even before the local repository

The repositories checked are controlled by these configuration properties.
저장소들은 환경구성 프로퍼티들에 의해서 통제 된다.

For example, org.ops4j.pax.url.mvn.repositories is a comma separate list of repository URLs specifying those remote repositories to be checked. So, to replace the defaults with a new repository at http://www.example.org/repo on the local machine:
예를 들면  rg.ops4j.pax.url.mvn.repositories 는 체크되기 위해 그래서 로컬머신의 http://www.example.org/repo 에 새 저장소를 기본 값으로 바꾸기 위해 원격 저장소를 열거하는 콤마로 구분된 저장소 URL들의 목록이다. 

karaf@root:/> config:edit org.ops4j.pax.url.mvn
karaf@root:/> config:proplist                  
   service.pid = org.ops4j.pax.url.mvn
   org.ops4j.pax.url.mvn.defaultRepositories = file:/opt/development/karaf/assembly/target/apache-felix-karaf-1.2.0-SNAPSHOT/system@snapshots
   org.ops4j.pax.url.mvn.repositories = http://repo1.maven.org/maven2,
                                        http://svn.apache.org/repos/asf/servicemix/m2-repo
   below = list of repositories and even before the local repository
karaf@root:/> config:propset org.ops4j.pax.url.mvn.repositories http://www.example.org/repo
karaf@root:/> config:update

By default, snapshots are disabled. To enable an URL for snapshots append @snapshots. For example
기본적으로 스냅샷은 사용할 수 없다.  스냅샷 URL을 사용가능하게 하기 위해  @snapshots를 추가 한다. 예를 들면

http://www.example.org/repo@snapshots

Repositories on the local machine are supported through file:/ URLs
로컬 머신의 저장소는 file:/ URL들을 통해서 지원된다.

Bundle start-level (번들 시작 레벨)

Available since Karaf 2.0 Karaf 2.0 이후 사용 가능

By default, the bundles deployed through the feature mechanism will have a start-level equals to the value defined in the configuration file config.properties with the variable karaf.startlevel.bundle=80. This value can be changed using the xml attribute start-level.
기본적으로, 기능 매커니즘을 통해서 배포되는 번들들은 변수  karaf.startlevel.bundle=80로  환경 구성 파일 config.properties 에서 정의된 값에 같은 시작레벨을 가지게 될 것이다. 이 값은 xml start-level 속성을 사용하여 변경 될수 있다.

  <feature name='my-project' version='1.0.0'>
    <feature version='2.4.0'>camel-spring</feature>
    <bundle start-level='80'>mvn:com.mycompany.myproject/myproject-dao</bundle>    
    <bundle start-level='85'>mvn:com.mycompany.myproject/myproject-service</bundle>
    <bundle start-level='85'>mvn:com.mycompany.myproject/myproject-camel-routing</bundle>
  </feature> 

The advantage in defining the bundle start-level is that you can deploy all your bundles including any required 'infrastructure' bundles (e.g Camel, ActiveMQ) at the same time and you will have the guarantee when using Spring Dynamic Modules or Blueprint that the Spring context will not be created without all the required services installed.
번들에 시작 레벨을 정의하는것에 잇점은 당신이 어떤 필요한 '인프라' 번들들(예를 들면 Camel, ActiveMQ)을 같은 시간에 포함하여 모든 번들을 배포 할 수 있다는 것이고 당신은 Spring Dynamic Modules 나 Blueprint를 사용할때 Spring 컨텍스트가 모든 필요한 설치된 서비스들 없이 생성되지 않을 것이라는 보증을 가지게 될 것이다.

Bundle 'stop/start' 번들의 종료와 시작

The OSGI specification allows for installing a bundle without starting it. To use this functionality, simply add the following attribute in your <bundle> definition
OSGI 명세서는 그것을 시작하지 않고 번들을 설치 하는 것을 허용한다.  그것의 기능성을 사용하기 위해, 단순히 다음 속성을 당신의 <bundle>에 정의 를 추가 하라

  <feature name='my-project' version='1.0.0'>
    <feature version='2.4.0'>camel-spring</feature>
    <bundle start-level='80' start='false'>mvn:com.mycompany.myproject/myproject-dao</bundle>    
    <bundle start-level='85' start='false'>mvn:com.mycompany.myproject/myproject-service</bundle>
    <bundle start-level='85' start='false'>mvn:com.mycompany.myproject/myproject-camel-routing</bundle>
  </feature> 

On Karaf 2.x, the start-level was not considered during the feature startup, but only the order in which bundles
are defined in your feature.xml. Starting with Karaf 3.x, the start-level is considered correctly.
If you need to use the old behavior you can uncomment and change the respectStartLvlDuringFeatureStartup variable in org.apache.karaf.features.xml to false. But please be aware that it will be removed in 4.0 and should therefore be used only temporarily.
Karaf 2.x 에서 시작 레벨은 기능을 시작 하는 동안은 고려되지 안는다 그러나 단지 당신의 feature.xml 에서 번들의 순서가 정의되어 있다. Karaf 3.x를 시작 하는 것은 정확하게 시작 레벨이 고려되었다.
만약 당신이 이전 행위를 사용할 필요가 있을때 당신이 주석을 달지 않을수 있고 org.apache.karaf.features.xml 에서 respectStartLvlDuringFeatureStartup 변수를 false로  변경 할 수 있다.  그러나 주의해라 4.0에서는 제거 될 것이고 그러므로 단지 임시로 단지 사용되게 될 것이다.

Bundle 'dependency' (의존관계 번들)

A bundle can be flagged as being a dependency. Such information can be used by resolvers to compute the full list of bundles to be installed.
번들은 의돈관계가 되는 것으로써 기를 올릴수 있다.(알릴수 있다.) 그런 정보는 설치되어 있는 번들의 전체 목록을 계산하기 위한 해결자에 의해서 사용 될 수 있다.

Dependent features (의존 기능)

Dependent features are useful when a given feature depends on another feature to be installed. Such a dependency can be expressed easily in the feature definition:
의존 기능은 주어진 기능이 다른 설치되어있는 다른 기능에 의존할때 유용하다. 그런 의존관계는 기능정의에서 쉽게 표현된다.

<feature name="jbi">
  <feature>nmr</feature>
  ...
</feature>

The effect of such a dependency is to automatically install the required nmr feature when the jbi feature is installed.
그런 의존관계의 효과는 JBI 기능이 설치될때  자동적으로  필요한 NMR 기능을 설치하기 위해서 이다.

A version range can be specified on the feature dependency:
기능 의존관계에서 버전 범위가 명시될 수 있다.

<feature name="spring-dm">
  <feature version="[2.5.6,4)">spring</feature>
  ...
</feature>

In such a case, if no matching feature is already installed, the feature with the highest version available in the range will be installed. If a single version is specified, this version will be chosen. If nothing is specified, the highest available will be installed.
이런 경우에, 만약 이미 설치된 기능과 일치 하는것이 없으면,  이 범위에서 가장 높은 버전의 사용 가능한 기능이  설치 되게 될 것이다. 만약 단일 버전이 명시되어 있으면 그 버전이 선택 될 것이다. 만약 명시된것이 없다면 사용 가능한 가장 높은 것이 설치 될 것이다.

Configurations (환경 구성)

The configuration section allows for declaring deployment configuration of the OSGi Configuration Admin service along a set of bundles.
번들 세트에 따라 환경 구성 섹션은 OSGi 환경 구성 관리 서비스의 배포 환경 구성을 선언 하는 것을 허용한다.

Here is an example of such a configuration:
그런 환경 구성의 예가 여기 있다.

<config name="com.foo.bar">
  myProperty = myValue
</config>

The name attribute of the configuration element will be used as the ManagedService PID for the configuration set in the Configuration Admin service. When using a ManagedServiceFactory, the name attribute is servicePid-_aliasId_, where servicePid is the PID of the ManagedServiceFactory and aliasId is a label used to uniquely identify a particular service (an alias to the factory generated service PID).
configuration 엘리먼트의 name  속성은 환경구성 관리 서비스에서 환경 구성 세트를 위한 ManagedService PID 로써 사용될 것이다. ManagedServiceFactory를 사용할때  name  속성은 servicePid-_aliasId_이고 servicePid 는 ManagedServiceFactory의 PID 이고 aliasId 는 특히 서비스를 유일하게 구분하기 위해 사용되는 라벨이다. ( factory에 생성된 서비스 PID의 별명 )

Deploying such a configuration has the same effect as dropping a file named com.foo.bar.cfg into the etc folder.
그런 환경 구성을 배포 하는 것은 etc 폴더에 com.foo.bar.cfg 로 이름이 된 파일을 넣는 것과 같은 효과 이다.

The content of the configuration element is set of properties parsed using the standard java property mechanism.
configuration 엘리먼트의 내용은 standard java property mechanism을 사용하여 파싱된 프로퍼티의 세트이다. 

Such configuration as usually used with Spring-DM or Blueprint support for the Configuration Admin service, as in the following example, but using plain OSGi APIs will of course work the same way:
보통 Spring-DM 이나 Blueprint 로 사용되는 그런 환경 구성은 환경구성 관리 서비스를 위해 지원된다. 다음 예처럼, 그러나 순수 OSGi API 들을 사용 하는 것은 물론 같은 방법으로 동작하게 될 것이다.

<bean ...>
    <property name="propertyName" value="${myProperty}" />
</bean>

<osgix:cm-properties id="cmProps" persistent-id="com.foo.bar">
    <prop key="myProperty">myValue</prop>
</osgix:cm-properties>
<ctx:property-placeholder properties-ref="cmProps" />

There may also be cases where you want to make the properties from multiple configuration files available to your bundle context. This is something you may want to do if you have a multi-bundle application where there are application properties used by multiple bundles, and each bundle has its own specific properties. In that case, <ctx:property-placeholder> won't work as it was designed to make only one configuration file available to a bundle context.
To make more than one configuration file available to your bundle-context you would do something like this:
또한 당신이 번들의 컨텍스트에 사용 가능한 복합 환경 구성 파일로부터 프로퍼티를 만들기를  원하는 케이스가 될 것이다.  이것은 무언가 당신이 하기를 원할지 모른다. 만약 당신이 복합 번들에 의해 사용될 프로퍼티를 가진 복합 번들 어플리케이션을 가지고 있으면 각가의 번들은 자신의 특정 프로퍼티를 가질 것이다. 이 경우에 <ctx:property-placeholder> 는 번들 컨텍스트에 단지 하나의 사용가능한 환경 구성 파일을 만들기 위해 설계됨으로써  동작하지 않을 것이다.  당신의 번들 컨텍스트에 하나의 환경 구성 파일 이상을 만들기 위해 당신은 이렇게 해야 할 것이다.  

<beans:bean id="myBundleConfigurer"
            class="org.springframework.beans.factory.config.PropertyPlaceholderConfig">
    <beans:property name="ignoreUnresolvablePlaceholders" value="true"/>
    <beans:property name="propertiesArray">
        <osgix:cm-properties id="myAppProps" persistent-id="myApp.props"/>
        <osgix:cm-properties id="myBundleProps" persistent-id="my.bundle.props"/>
    </beans:property>
</beans:bean>

In this example, we are using SpringDM with osgi as the primary namespace. Instead of using ctx:context-placeholder we are using the "PropertyPlaceholderConfig" class. Then we are passing in a beans array and inside of that array is where we set our osgix:cm-properties elements. This element "returns" a properties bean.
이 예에서, 우리는 첫번째 네임스페이스로 osgi로 SpringDM을 사용하고 있다.  ctx:context-placeholder 를 사용하는 것 대신에 우리는  PropertyPlaceholderConfig 클래스를 사용 할 것이다. 그러면 우리는 beans 배열과 그 osgix:cm-properties 엘리먼트를 설정한 그 배열 안쪽에 전달 될 것이다. 이 엘리먼트는 프로퍼티 빈으로 "반환된다."

For more information about using the Configuration Admin service in Spring-DM, see the Spring-DM documentation.  Spring-DM 에서 환경구성 관리 서비스를 사용하는 것에 대한 좀 더 많은 정보를 위해, Spring-DM documentation를 보라

Configuration files(환경 구성 파일)

In certain cases it is needed not only to provide configurations for the configuration admin service but to add additional
configuration files e.g. a configuration file for jetty (jetty.xml). It even might be helpful to deploy a configuration
file instead of a configuration for the config admin service since. To achieve this the attribute finalname shows the
final destination of the configfile, while the value references the Maven artifact to deploy.

<configfile finalname="/etc/jetty.xml">mvn:org.apache.karaf/apache-karaf/2.3.7-SNAPSHOT/xml/jettyconfig</configfile>

Feature resolver (기능 해결자)

The resolver attribute on a feature can be set to force the use of a given resolver instead of the default resolution process. A resolver will be use to obtain the list of bundles to actually install for a given feature.
The default resolver will simply return the list of bundles provided in the feature description.
The OBR resolver can be installed and used instead of the standard one. In that case, the resolver will use the OBR service
to determine the list of bundles to install (bundles flagged as dependency will only be used as possible candidates to solve
various constraints).

Commands (명령어들)

Repository management (저장소 관리)

The following commands can be used to manage the list of descriptors known by Karaf. They use URLs pointing to features descriptors. These URLs can use any protocol known to the Apache Karaf, the most common ones being http, file and mvn.
다음 명령어들은 Karaf에 의해 알려진 설명자의 목록을 관리하기 위해 사용 될수 있다. 그들은  기능 설명자를 가리키기 위해 URL들을 사용한다. 그 URL들은 Apache Karaf에 알려진  모든 프로토콜을 사용 할 수 있으며 그 가장 일반적인 것은 http, file 그리고 mvn 이 된다.

features:addUrl      Add a list of repository URLs to the features service
features:removeUrl   Remove a list of repository URLs from the features service
features:listUrl     Display the repository URLs currently associated with the features service.
features:refreshUrl  Reload the repositories to obtain a fresh list of features

Karaf maintains a persistent list of these repositories so that if you add one URL and restart Karaf, the features will still be available.
Karaf는 그들 저장소의 지속된 리스트를 유지관리한다. 그래서 만약 당신이 하나의 URL을 추가 하고 Karaf를 재시작하면 그 기능은 사용가능하게 될 것이다.

The refreshUrl command is mostly used when developing features descriptors: when changing the descriptor, it can be
handy to reload it in the Kernel without having to restart it or to remove then add the URL again.
refreshUrl  명령어는 대부분  기능 기술자를 개발 할때 사용된다. 기술자를 변경 할때 그것은 커널에 재시작 하거나 URL을 제거 후 다시 시작 하는 것을 해야할 필요 없이 그것을 재 로딩 하는 것을 편리하게 할 수 있다.

Features management (기능 관리)

features:install
features:uninstall
features:list

Examples (예제)

1. Install features using mvn handler
1. mvn 핸들러를 사용하여 기능을 설치하라

features:addUrl mvn:org.apache.servicemix.nmr/apache-servicemix-nmr/1.0.0-m2/xml/features
features:install nmr

2. Use file handler to deploy features file
2. 기능 파일을 배포하기 위해 파일 핸들러 사용하라

features:addUrl file:base/features/features.xml

Note: The path is relative to the Apache Karaf installation directory
주의 : 이 경로는 Apache Karaf 설치 디렉토리에 관련되어 있다.

3. Deploy bundles from file system without using Maven
3. Maven을 사용하지 않고 파일 시스템으로 부터 번들 배포하기

As we can use file:// as protocol handler to deploy bundles, you can use the following syntax to deploy bundles when they are located in a directory which is not available using Maven
번들을 배포하기 ㅜ이해 우리가 프로토콜 핸들로서 file:// 을 사용할 수 있기 때문에 당신은 Maven을 사용하는 것이 가능하지 않는 디렉토리에 위치할때 번들을 배포하기 위해 다음 구문을 사용 할수 있다. 

<features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0">
   <feature name="spring-web" version="2.5.6.SEC01">
      <bundle>file:base/bundles/spring-web-2.5.6.SEC01.jar</bundle>
   </feature>
</features>

Note: The path is relative to the Apache Karaf installation directory

Service configuration (서비스 환경 구성)

A simple configuration file located in etc/org.apache.karaf.features.cfg can be modified to customize the behavior when starting the Kernel for the first time.
etc/org.apache.karaf.features.cfg 에 위치한 단순한 환경 구성 파일은  첫번째로 커털이 시작될때 행동을 커스터마이즈하기 위해 변경 될수 있다. 
This configuration file contains two properties:
환경 구성 파일은 두가지 프로퍼티를 포함한다.

• featuresBoot: a comma separated list of features to install at startup
  featuresBoot : 시작에서 설치되기 위해 콤마로 구분된 기능의 목록
• featuresRepositories: a comma separated list of feature repositories to load at startup
  featuresRepositories : 시작에서 로드 하기 위해 콤마로 구분된 기능 저장소의 목록 

This configuration file is of interest if you plan to distribute a customized Karaf distribution having pre-installed features. Such a process is detailed in the building custom distributions section.
이 환경 설정 파일은  만약 당신이  미리 설치된 기능을 가지고 있는 사용자정의된 Karaf의 배포판을 배포 하는 것을 계확한다면 그 절차는 building custom distributions 섹션에 자세하게 되어 있다.