OSGi Alliance 는 OSGi Service Platform 릴리스 4 의 기능 및 기능을 정의하는 독립 조직입니다. OSGi Service Platform은 복잡한 소프트웨어 애플리케이션의 구축, 배포 및 관리를 단순화하는 오픈 사양 세트입니다.

OSGi 기술은 종종 Java용 동적 모듈 시스템이라고 합니다. OSGi는 번들을 사용하여 Java 구성 요소를 모듈식으로 배포하고 종속 항목, 버전 관리, 클래스 경로 제어 및 클래스 로드를 처리하는 Java용 프레임워크입니다. OSGi의 라이프사이클 관리를 사용하면 JVM을 종료하지 않고 번들을 로드, 시작 및 중지할 수 있습니다.

OSGi는 Java에 가장 적합한 런타임 플랫폼, 우수한 클래스 로드 아키텍처, 서비스 레지스트리를 제공합니다. 번들은 서비스를 내보내고, 프로세스를 실행하고, 종속성을 관리할 수 있습니다. 각 번들에는 OSGi 컨테이너에서 관리하는 요구 사항이 있을 수 있습니다.

Fuse는 Apache Felix 를 기본 OSGi 구현으로 사용합니다. 프레임워크 계층은 번들을 설치하는 컨테이너를 형성합니다. 프레임워크는 동적이고 확장 가능한 방식으로 번들 설치 및 업데이트를 관리하고 번들과 서비스 간의 종속성을 관리합니다.

OSGi 프레임워크에는 다음이 포함됩니다.

프레임워크의 각 계층은 해당 계층에 따라 다릅니다. 예를 들어 라이프사이클 계층에는 모듈 계층이 필요합니다. 모듈 계층은 라이프사이클 및 서비스 계층 없이 사용할 수 있습니다.

OSGi 서비스는 이름/값 쌍으로 정의된 서비스 속성이 있는 Java 클래스 또는 서비스 인터페이스입니다. 서비스 속성은 동일한 서비스 인터페이스를 제공하는 서비스 공급자 간에 구별됩니다.

OSGi 서비스는 서비스 인터페이스에 의해 의미 체계적으로 정의되며 서비스 오브젝트로 구현됩니다. 서비스의 기능은 구현하는 인터페이스에 의해 정의됩니다. 따라서 다른 애플리케이션이 동일한 서비스를 구현할 수 있습니다.

서비스 인터페이스를 사용하면 번들이 구현이 아닌 바인딩 인터페이스로 상호 작용할 수 있습니다. 구현 세부 정보를 가능한 한 적은 수만큼 사용하여 서비스 인터페이스를 지정해야 합니다.

OSGi 프레임워크에서 서비스 계층은 게시, 찾기, 서비스 모델을 사용하여 1.5절. “OSGi 번들” 와 포함된 구성 요소 간의 통신을 제공합니다. 서비스 계층에는 다음과 같은 서비스 레지스트리가 포함되어 있습니다.

서비스는 번들에 의해 소유되며, 내에서 실행됩니다. 번들은 하나 이상의 Java 인터페이스 아래에 프레임워크 서비스 레지스트리에 서비스 구현을 등록합니다. 따라서 프레임워크를 제어하는 다른 번들에서 서비스의 기능을 사용할 수 있으며 다른 번들은 서비스를 조회하고 사용할 수 있습니다. 조회는 Java 인터페이스 및 서비스 속성을 사용하여 수행됩니다.

각 번들은 인터페이스의 정규화된 이름과 해당 속성을 사용하여 서비스 레지스트리에 여러 서비스를 등록할 수 있습니다. 번들에서는 LDAP 구문과 함께 이름 및 속성을 사용하여 서비스의 서비스 레지스트리를 쿼리합니다.

번들은 게시, 검색 및 바인딩을 포함한 런타임 서비스 종속성 관리 활동을 담당합니다. 또한 번들은 번들에 바인딩된 서비스의 동적 가용성 (배타 또는 출발)으로 인한 변경 사항에도 대응할 수 있습니다.

환경을 수정하지 않고도 설치의 bin 하위 디렉터리에서 Karaf 런타임을 직접 시작할 수 있습니다. 그러나 다른 폴더에서 시작하려면 다음과 같이 Karaf 설치의 bin 디렉토리를 PATH 환경 변수에 추가해야 합니다.

Windows

set PATH=%PATH%;InstallDir\bin

Linux/UNIX

export PATH=$PATH,InstallDir/bin`

설치 디렉토리에서 Karaf 런타임을 시작하는 경우 다음 명령을 사용합니다.

Windows

bin\fuse.bat

Linux/UNIX

./bin/fuse

Karaf가 올바르게 시작되면 콘솔에 다음이 표시됩니다.

Red Hat Fuse starting up. Press Enter to open the shell now...
100% [========================================================================]

Karaf started in 8s. Bundle stats: 220 active, 220 total

 ____          _   _   _       _     _____
|  _ \ ___  __| | | | | | __ _| |_  |  ___|   _ ___  ___
| |_) / _ \/ _` | | |_| |/ _` | __| | |_ | | | / __|/ _ \
|  _ <  __/ (_| | |  _  | (_| | |_  |  _|| |_| \__ \  __/
|_| \_\___|\__,_| |_| |_|\__,_|\__| |_|   \__,_|___/___|

  Fuse (7.x.x.fuse-xxxxxx-redhat-xxxxx)
  http://www.redhat.com/products/jbossenterprisemiddleware/fuse/

Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.

Open a browser to http://localhost:8181/hawtio to access the management console

Hit '<ctrl-d>' or 'shutdown' to shutdown Red Hat Fuse.

karaf@root()>

서버 모드에서 시작하면 로컬 콘솔 없이 백그라운드에서 Apache Karaf가 실행됩니다. 그런 다음 원격 콘솔을 사용하여 실행 중인 인스턴스에 연결합니다. 자세한 내용은 17.2절. “원격 연결 및 연결 해제” 을 참조하십시오.

서버 모드에서 Karaf를 시작하려면 다음을 실행합니다.

Windows

bin\start.bat

Linux/UNIX

./bin/start

프로덕션 환경에서는 로컬 콘솔만 사용하여 런타임 인스턴스에 액세스할 수 있어야 합니다. 즉, SSH 콘솔 포트를 통해 원격으로 런타임에 연결할 수 없습니다. 다음 명령을 사용하여 클라이언트 모드에서 런타임을 시작하여 이 작업을 수행할 수 있습니다.

Windows

bin\fuse.bat client

Linux/UNIX

./bin/fuse client

디버그 모드에서 Fuse를 실행하면 오류를 보다 효율적으로 식별하고 해결할 수 있습니다. 이 옵션은 기본적으로 비활성화되어 있습니다. 활성화된 경우 Fuse는 포트 5005 에서 JDWP 소켓을 시작합니다.

디버그 모드에서 Fuse를 실행하는 방법은 세 가지가 있습니다.

$ export KARAF_DEBUG=1
$ bin/start

$ bin/fuse debug

$ bin/fuse debugs

fuse 또는 fuse 클라이언트를 실행하여 Karaf 인스턴스를 시작한 경우 karaf > 프롬프트에서 다음 중 하나를 수행하여 중지할 수 있습니다.

다음과 같이 InstallDir/bin 디렉토리에서 stop( .CAST)을 호출하여 로컬로 실행 중인 Karaf 인스턴스(루트 컨테이너)를 중지 할 수 있습니다.

Windows

bin\stop.bat

Linux/UNIX

./bin/stop

Karaf stop 스크립트에서 호출한 종료 메커니즘은 Apache Tomcat에서 구현된 종료 메커니즘과 유사합니다. Karaf 서버는 종료 알림을 수신하기 위해 전용 종료 포트(SSH 포트와동일하지 않음 )를 엽니다. 기본적으로 shutdown 포트는 임의로 선택되지만 원하는 경우 특정 포트를 사용하도록 구성할 수 있습니다.

필요한 경우 InstallDir/etc/config.properties 파일에서 다음 속성을 설정하여 종료 포트를 사용자 지정할 수 있습니다.

17.3절. “원격 컨테이너 중지” 에 설명된 대로 원격 호스트에서 실행 중인 컨테이너 인스턴스를 중지할 수 있습니다.

노출된 모든 포트에는 사용자 인증이 필요하고 사용자가 처음에 정의되어 있지 않기 때문에 Apache Karaf 런타임은 기본적으로 네트워크 공격에 대해 보호됩니다. 즉, Apache Karaf 런타임은 기본적으로 원격으로 액세스할 수 없습니다.

원격으로 런타임에 액세스하려면 여기에 설명된 대로 먼저 보안 구성을 사용자 지정해야 합니다.

Karaf 컨테이너에 대한 원격 액세스를 활성화하려면 컨테이너를 시작하기 전에 보안 JAAS 사용자를 만들어야 합니다.

기본적으로 컨테이너에 대한 JAAS 사용자는 정의되어 있지 않으므로 원격 액세스를 효과적으로 비활성화합니다(로그인할 수 없음).

보안 JAAS 사용자를 생성하려면 InstallDir/etc/users.properties 파일을 편집하고 다음과 같이 새 user 필드를 추가합니다.

Username=Password,admin

여기서 Username 및 Password 는 새 사용자 자격 증명입니다. admin 역할은 이 사용자에게 컨테이너의 모든 관리 및 관리 기능에 액세스할 수 있는 권한을 제공합니다.

앞에 0인 숫자 사용자 이름을 정의하지 마십시오. 이러한 사용자 이름은 항상 로그인 시도가 실패합니다. 콘솔이 사용하는 Karaf 쉘은 입력이 숫자로 표시될 때 선행 0이 삭제되기 때문입니다. 예를 들면 다음과 같습니다.

karaf@root> echo 0123
123
karaf@root> echo 00.123
0.123
karaf@root>

Karaf 컨테이너는 Cryostat 프로토콜, Karaf 명령 콘솔 및 Fuse 관리 콘솔을 통해 액세스를 규제하는 역할 기반 액세스 제어를 지원합니다. 사용자에게 역할을 할당할 때 표 3.1. “액세스 제어를 위한 표준 역할” 에 설명된 액세스 수준을 제공하는 표준 역할 세트 중에서 선택할 수 있습니다.

역할 기반 액세스 제어에 대한 자세한 내용은 역할 기반 액세스 제어를 참조하십시오.

다음은 컨테이너에서 노출하는 포트는 다음과 같습니다.

다음 조건이 모두 충족될 때마다 원격 콘솔 포트에 액세스할 수 있습니다.

예를 들어 컨테이너가 실행 중인 동일한 머신의 원격 콘솔 포트에 로그인하려면 다음 명령을 입력합니다.

./client -u Username -p Password

여기서 Username 및 Password 는 ssh 역할이 있는 JAAS 사용자의 자격 증명입니다. 원격 포트를 통해 Karaf 콘솔에 액세스하는 경우 권한은 etc/users.properties 파일의 사용자에게 할당된 역할에 따라 달라집니다. 전체 콘솔 명령 세트에 액세스하려면 사용자 계정에 admin 역할이 있어야합니다.

다음 조치를 사용하여 원격 콘솔 포트에서 보안을 강화할 수 있습니다.

Cryostat 포트는 기본적으로 활성화되며 JAAS 인증에 의해 보호됩니다. Cryostat 포트에 액세스하려면 하나 이상의 로그인 인증 정보 세트를 사용하여 JAAS를 구성해야 합니다. Cryostat 포트에 연결하려면 Cryostat 클라이언트(예: jconsole)를 열고 다음 Cryostat URI에 연결합니다.

service:jmx:rmi:///jndi/rmi://localhost:1099/karaf-root

연결하려면 유효한 JAAS 자격 증명도 제공해야 합니다.

Fuse Console은 JAAS 인증에 의해 이미 보호됩니다. SSL 보안을 추가하려면 Cryostat HTTP 서버 보안을 참조하십시오.

빠른 시작을 돕기 위해 Maven archetype을 호출하여 Maven 프로젝트의 초기 개요를 생성할 수 있습니다(MM archetype은 프로젝트 마법사와 유사합니다). 다음 Maven archetype은 OSGi 번들을 빌드하는 프로젝트를 생성합니다.

Apache Camel OSGi archetype은 OSGi 컨테이너에 배포할 수 있는 경로를 빌드하기 위한 프로젝트를 생성합니다.

다음 예제에서는 Maven archetype 명령을 좌표와 함께 GroupId:ArtifactId:Version , 을 사용하여 camel-blueprint 프로젝트를 생성하는 방법을 보여줍니다.

mvn archetype:generate \
 -DarchetypeGroupId=org.apache.camel.archetypes \
 -DarchetypeArtifactId=camel-archetype-blueprint \
 -DarchetypeVersion=2.23.2.fuse-7_10_0-00018-redhat-00001

이 명령을 실행한 후 Maven에서 GroupId,ArtifactId, Version 을 지정하라는 메시지를 표시합니다.

기본적으로 이전 archetypes는 지정된 아티팩트 ID인 ArtifactId 와 이름이 동일한 새 디렉터리에 프로젝트를 생성합니다. 새 프로젝트에서 정의한 번들을 빌드하려면 명령 프롬프트를 열고 프로젝트 디렉터리(즉, pom.xml 파일이 포함된 디렉터리)로 이동하여 다음 Maven 명령을 입력합니다.

mvn install

이 명령의 영향은 모든 Java 소스 파일을 컴파일하여 ArtifactId/target 디렉터리에 번들 JAR을 생성한 다음 로컬 Maven 리포지토리에 생성된 JAR을 설치하는 것입니다.

이미 Maven 프로젝트가 있고 OSGi 번들을 생성하도록 수정하려면 다음 단계를 수행합니다.

프로젝트의 pom.xml 파일에서 패키지 유형을 번들로 변경하여 OSGi 번들을 생성하도록 Maven을 구성합니다. 다음 예와 같이 패키징 요소의 내용을 번들 로 변경합니다.

<project ... >
  ...
  <packaging>bundle</packaging>
  ...
</project>

이 설정의 영향은 Maven 번들 플러그인인 maven-bundle-plugin 을 선택하여 이 프로젝트에 대한 패키징을 수행하는 것입니다. 그러나 이 설정은 POM에 번들 플러그인을 명시적으로 추가할 때까지는 적용되지 않습니다.

Maven 번들 플러그인을 추가하려면 다음 샘플 플러그인 요소를 복사하여 프로젝트 pom.xml 파일의 project/build/plugins 섹션에 붙여넣습니다.

<project ... >
  ...
  <build>
    <defaultGoal>install</defaultGoal>
    <plugins>
      ...
    <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <version>3.3.0</version>
        <extensions>true</extensions>
        <configuration>
          <instructions>
            <Bundle-SymbolicName>${project.groupId}.${project.artifactId}
            </Bundle-SymbolicName>
            <Import-Package>*</Import-Package>
          </instructions>
        </configuration>
      </plugin>
    </plugins>
  </build>
  ...
</project>

여기서 bundle 플러그인은 instructions 요소의 설정으로 구성됩니다.

Apache CXF용 번들 플러그인 구성에 대한 몇 가지 구체적인 권장 사항은 5.3절. “번들로 웹 서비스 패키징” 에서 참조하십시오.

POM 파일에서 JDK 버전을 지정하는 것은 거의 항상 필요합니다. 코드에서 Java 언어의 최신 기능을 사용하는 경우(예: 일반, 정적 가져오기 등) POM에서 JDK 버전을 사용자 지정하지 않은 경우 Maven은 소스 코드를 컴파일하지 못합니다. JAVA_HOME 및 PATH 환경 변수를 JDK의 올바른 값으로 설정하는 것만으로는 충분하지 않으며 POM 파일도 수정해야 합니다.

POM 파일을 구성하려면 JDK 1.8에 도입된 Java 언어 기능을 허용하도록 다음 maven-compiler-plugin 플러그인을 POM에 추가합니다(아직 없는 경우).

<project ... >
  ...
  <build>
    <defaultGoal>install</defaultGoal>
    <plugins>
      ...
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
        </configuration>
      </plugin>
    </plugins>
  </build>
  ...
</project>

이 섹션에서는 Apache CXF 애플리케이션의 기존 Maven 프로젝트를 수정하여 프로젝트에서 Red Hat Fuse OSGi 컨테이너에 배포에 적합한 OSGi 번들을 생성하는 방법을 설명합니다. Maven 프로젝트를 변환하려면 프로젝트의 POM 파일과 프로젝트의 블루프린트 파일( META-INF/spring에 배치됨)을 수정해야 합니다.

번들을 생성하도록 Maven POM 파일을 구성하려면 기본적으로 POM의 패키지 유형을 번들로 변경하고 POM 번들 플러그인을 POM에 추가하는 두 가지 변경 사항이 있습니다. 자세한 내용은 5.1절. “번들 프로젝트 생성”의 내용을 참조하십시오.

애플리케이션이 Apache CXF 구성 요소를 사용하려면 해당 패키지를 애플리케이션의 번들로 가져와야 합니다. Apache CXF의 종속성이 복잡하기 때문에 Maven 번들 플러그인 또는 bnd 툴을 사용하여 필요한 가져오기를 자동으로 결정할 수 없습니다. 명시적으로 선언해야 합니다.

다음 패키지를 번들로 가져와야 합니다.

javax.jws
javax.wsdl
javax.xml.bind
javax.xml.bind.annotation
javax.xml.namespace
javax.xml.ws
org.apache.cxf.bus
org.apache.cxf.bus.spring
org.apache.cxf.bus.resource
org.apache.cxf.configuration.spring
org.apache.cxf.resource
org.apache.cxf.jaxws
org.springframework.beans.factory.config

예 5.1. “필수 가져오기 패키지 구성” 필수 패키지를 가져오기 위해 POM에서 Maven 번들 플러그인을 구성하는 방법을 보여줍니다. 필수 가져오기 패키지는 Import-Package 요소 내에 쉼표로 구분된 목록으로 표시됩니다. 와일드카드인 * 의 모양을 목록의 마지막 요소로 기록해 둡니다. 와일드카드를 사용하면 현재 번들의 Java 소스 파일을 스캔하여 가져올 추가 패키지를 검색할 수 있습니다.

<project ... >
    ...
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <extensions>true</extensions>
                <configuration>
                    <instructions>
                        ...
                        <Import-Package>
                            javax.jws,
                            javax.wsdl,
                            javax.xml.bind,
                            javax.xml.bind.annotation,
                            javax.xml.namespace,
                            javax.xml.ws,
                            org.apache.cxf.bus,
                            org.apache.cxf.bus.spring,
                            org.apache.cxf.bus.resource,
                            org.apache.cxf.configuration.spring,
                            org.apache.cxf.resource,
                            org.apache.cxf.jaxws,
                            org.springframework.beans.factory.config,
                            *
                        </Import-Package>
                        ...
                    </instructions>
                </configuration>
            </plugin>
        </plugins>
    </build>
    ...
</project>

웹 서비스 프로젝트에서는 일반적으로 코드를 생성해야 합니다. Apache CXF는 Cryostat-WS 프런트 엔드에 대한 두 개의 Maven 플러그인을 제공하므로 코드 생성 단계를 빌드에 통합할 수 있습니다. 플러그인의 선택은 다음과 같이 Java 우선 접근 방식 또는 WSDL 우선 접근 방식을 사용하여 서비스를 개발하는지 여부에 따라 달라집니다.

OSGi 구성 관리 서비스는 구성 설정을 OSGi 번들에 전달하는 메커니즘을 정의합니다. 구성에 이 서비스를 사용할 필요는 없지만 일반적으로 번들 애플리케이션을 구성하는 가장 편리한 방법입니다. 블루프린트는 OSGi 구성을 지원하여 OSGi 구성 관리 서비스에서 가져온 값을 사용하여 블루프린트 파일의 변수를 대체할 수 있습니다.

OSGi 구성 속성을 사용하는 방법에 대한 자세한 내용은 5.3.7절. “번들 플러그인 구성” 및 9.6절. “기능에 OSGi 구성 추가” 을 참조하십시오.

PID 문자열(symbolic-name 구문)은 OSGI 사양의 하이픈을 허용합니다. 그러나 하이픈은 Apache Felix.fileinstall 및 config:edit 쉘 명령으로 해석되어 "관리 서비스" 및 "관리 서비스 팩토리"를 구분합니다. 따라서 PID 문자열에서 하이픈을 사용하지 않는 것이 좋습니다.

Fuse는 FUSE_HOME/deploy 디렉터리의 파일을 모니터링하고 hot은 이 디렉터리의 모든 항목을 배포합니다. 파일이 이 디렉터리에 복사될 때마다 런타임 내에 설치되고 시작됩니다. 나중에 FUSE_HOME/deploy 디렉터리에서 파일을 업데이트하거나 삭제할 수 있으며 변경 사항은 자동으로 처리됩니다.

예를 들어, 번들을 빌드한 경우 ProjectDir/target/foo-1.0-SNAPSHOT.jar 에서는 다음과 같이 FUSE_HOME/deploy 디렉터리에 복사하여 이 번들을 배포할 수 있습니다(UNIX 플랫폼에서 작업한다고 가정).

% cp ProjectDir/target/foo-1.0-SNAPSHOT.jar FUSE_HOME/deploy

Fuse 콘솔에서 명령을 실행하여 수동으로 번들 배포 및 배포를 취소할 수 있습니다.

bundle:install 명령을 사용하여 OSGi 컨테이너에 하나 이상의 번들을 설치합니다. 이 명령에는 다음 구문이 있습니다.

bundle:install [-s] [--start] [--help] UrlList

여기서 UrlList 는 배포할 각 번들의 위치를 지정하는 공백으로 구분된 URL 목록입니다. 다음 명령 인수가 지원됩니다.

예를 들어, 번들 설치 및 시작, ProjectDir/target/foo-1.0-SNAPSHOT.jar 에서는 Karaf 콘솔 프롬프트에서 다음 명령을 입력합니다.

bundle:install -s file:ProjectDir/target/foo-1.0-SNAPSHOT.jar

번들을 설치 제거하려면 먼저 bundle:list 명령을 사용하여 번들 ID를 가져와야 합니다. 그러면 bundle ID를 인수로 사용하는 bundle:uninstall 명령을 사용하여 번들을 제거할 수 있습니다.

예를 들어 A Camel OSGi Service Unit 이라는 번들을 이미 설치한 경우 콘솔 프롬프트에서 bundle:list 를 입력하면 다음과 같은 출력이 생성될 수 있습니다.

...
[ 181] [Resolved   ] [            ] [       ] [   60] A Camel OSGi Service Unit (1.0.0.SNAPSHOT)

다음 콘솔 명령을 입력하여 ID 181 을 사용하여 번들을 제거할 수 있습니다.

bundle:uninstall 181

bundle:install 명령에 대한 위치 URL을 지정할 때 다음 스키마 유형을 포함하는 Fuse에서 지원하는 URL 체계를 사용할 수 있습니다.

기본적으로 기능은 기능 저장소라는 특수한 종류의 XML 파일에 새 기능 요소를 추가하여 생성됩니다. 기능을 생성하려면 다음 단계를 수행합니다.

OSGI-INF/blueprint

접미사 .xml .xml 이 있는 모든 파일은 블루프린트 구성 파일로 해석됩니다. 즉, 패턴과 일치하는 모든 파일, OSGI-INF/blueprint/*.xml.xml .xml입니다.

ProjectDir/src/main/resources/OSGI-INF/blueprint

http://www.osgi.org/xmlns/blueprint/v1.0.0

블루프린트 구성의 루트 요소는 블루프린트 이므로 블루프린트 XML 구성 파일에는 일반적으로 다음과 같은 개요 형식이 있습니다.

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
  ...
</blueprint>

Bundle-Blueprint: lib/account.xml, security.bp, cnf/*.xml

일반적으로 블루프린트 컨테이너는 초기화하는 동안 유예 기간을 통과하며 이 기간 동안 모든 필수 종속성을 해결하려고 시도합니다. 이 시점에서 필수 종속 항목을 확인할 수 없는 경우(기본 제한 시간은 5분), 컨테이너 초기화가 중단되고 번들이 시작되지 않습니다. Bundle-SymbolicName 매니페스트 헤더에 다음 설정을 추가하여 유예 기간을 구성할 수 있습니다.

예를 들어 유예 기간이 10초인 경우 매니페스트 파일에 다음 Bundle-SymbolicName 헤더를 정의할 수 있습니다.

Bundle-SymbolicName: org.fusesource.example.osgi-client;
 blueprint.graceperiod:=true;
 blueprint.timeout:= 10000

Bundle-SymbolicName 헤더의 값은 Semi-colon 구분 목록입니다. 여기서 첫 번째 항목은 실제 번들 심볼릭 이름, 두 번째 항목인 블루프린트.graceperiod:=true 에서는 유예 기간을 활성화하고 세 번째 항목인 블루프린트.timeout:= 10000 을 지정합니다.

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">

  <bean id="label" class="java.lang.String">
    <argument value="LABEL_VALUE"/>
  </bean>

  <bean id="myList" class="java.util.ArrayList">
    <argument type="int" value="10"/>
  </bean>

  <bean id="account" class="org.fusesource.example.Account">
    <property name="accountName" value="john.doe"/>
    <property name="balance" value="10000"/>
  </bean>

</blueprint>

마지막 8080 예제에서 참조하는 Account 클래스를 다음과 같이 정의할 수 있습니다.

package org.fusesource.example;

public class Account
{
    private String accountName;
    private int balance;

    public Account () { }

    public void setAccountName(String name) {
        this.accountName = name;
    }

    public void setBalance(int bal) {
        this.balance = bal;
    }
    ...
}

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
    xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.2.0">

    <ext:property-placeholder>
      <ext:location>file:etc/ldap.properties</ext:location>
    </ext:property-placeholder>
    ...
    <bean ...>
        <property name="myProperty" value="${myProperty}" />
    </bean>
</blueprint>

속성 소유자 구성 옵션의 사양은 http://aries.apache.org/schemas/blueprint-ext/blueprint-ext.xsd 에서 확인할 수 있습니다.

이 섹션에서는 OSGi 컨테이너에서 간단한 OSGi 서비스를 생성, 빌드 및 배포하는 방법을 설명합니다. 서비스는 간단한 Hello World Java 클래스이며 OSGi 구성은 블루프린트 구성 파일을 사용하여 정의됩니다.

Maven 빠른 시작 archetype을 사용하여 프로젝트를 생성하려면 다음과 같은 사전 요구 사항이 있어야 합니다.

maven-archetype-quickstart archetype은 일반 Maven 프로젝트를 생성한 다음 원하는 목적에 맞게 사용자 지정할 수 있습니다. 좌표를 사용하여 Maven 프로젝트를 생성하려면 org.fusesource.example:osgi-service 를 입력합니다.

mvn archetype:create
-DarchetypeArtifactId=maven-archetype-quickstart
-DgroupId=org.fusesource.example
-DartifactId=osgi-service

이 명령의 결과는 생성된 프로젝트의 파일이 포함된 ProjectDir/osgi-service 디렉터리입니다.

다음과 같이 OSGi 번들을 생성하려면 POM 파일을 사용자 지정해야 합니다.

ProjectDir/osgi-service/src/main/java/org/fusesource/example/service 하위 디렉토리를 생성합니다. 이 디렉터리에서 원하는 텍스트 편집기를 사용하여 파일 HelloWorldSvc.java 를 생성하고 예 12.3. “The HelloWorldSvc Interface” 의 코드를 추가합니다.

package org.fusesource.example.service;

public interface HelloWorldSvc
{
    public void sayHello();
}

ProjectDir/osgi-service/src/main/java/org/fusesource/example/service/impl 하위 디렉토리를 생성합니다. 이 디렉터리에서 원하는 텍스트 편집기를 사용하여 파일 HelloWorldSvcImpl.java 를 생성하고 예 12.4. “HelloWorldSvcImpl 클래스” 의 코드를 추가합니다.

package org.fusesource.example.service.impl;

import org.fusesource.example.service.HelloWorldSvc;

public class HelloWorldSvcImpl implements HelloWorldSvc {

    public void sayHello()
    {
        System.out.println( "Hello World!" );
    }

}

블루프린트 구성 파일은 클래스 경로의 OSGI-INF/blueprint 디렉터리에 저장된 XML 파일입니다. 프로젝트에 블루프린트 파일을 추가하려면 먼저 다음 하위 디렉터리를 생성합니다.

ProjectDir/osgi-service/src/main/resources
ProjectDir/osgi-service/src/main/resources/OSGI-INF
ProjectDir/osgi-service/src/main/resources/OSGI-INF/blueprint

여기서 src/main/resources 는 모든 JAR 리소스의 표준 Maven 위치입니다. 이 디렉터리에 있는 리소스 파일은 생성된 번들 JAR의 루트 범위에 자동으로 패키지됩니다.

예 12.5. “서비스 내보내기를 위한 블루프린트 파일” 빈 요소를 사용하여 HelloWorldSvc 8080을 만든 다음 service 요소를 사용하여ans를 OSGi 서비스로 내보내는 샘플 블루프린트 파일을 표시합니다.

ProjectDir/osgi-service/src/main/resources/OSGI-INF/blueprint 디렉터리 아래에서 원하는 텍스트 편집기를 사용하여 config.xml 을 생성하고 예 12.5. “서비스 내보내기를 위한 블루프린트 파일” 에서 XML 코드를 추가합니다.

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">

  <bean id="hello" class="org.fusesource.example.service.impl.HelloWorldSvcImpl"/>

  <service ref="hello" interface="org.fusesource.example.service.HelloWorldSvc"/>

</blueprint>

osgi-service 프로젝트를 설치하고 실행하려면 다음 단계를 수행합니다.

이 섹션에서는 OSGi 컨테이너에 간단한 OSGi 클라이언트를 생성, 빌드 및 배포하는 방법을 설명합니다. 클라이언트는 OSGi 레지스트리에서 간단한 Hello World 서비스를 찾고 sayHello() 메서드를 호출합니다.

Maven 빠른 시작 archetype을 사용하여 프로젝트를 생성하려면 다음과 같은 사전 요구 사항이 있어야 합니다.

maven-archetype-quickstart archetype은 일반 Maven 프로젝트를 생성한 다음 원하는 목적에 맞게 사용자 지정할 수 있습니다. 좌표를 사용하여 Maven 프로젝트를 생성하려면 org.fusesource.example:osgi-client 를 입력합니다.

mvn archetype:create
-DarchetypeArtifactId=maven-archetype-quickstart
-DgroupId=org.fusesource.example
-DartifactId=osgi-client

이 명령의 결과는 생성된 프로젝트의 파일이 포함된 ProjectDir/osgi-client 디렉터리입니다.

다음과 같이 OSGi 번들을 생성하려면 POM 파일을 사용자 지정해야 합니다.

클라이언트 프로젝트에 블루프린트 파일을 추가하려면 먼저 다음 하위 디렉터리를 생성합니다.

ProjectDir/osgi-client/src/main/resources
ProjectDir/osgi-client/src/main/resources/OSGI-INF
ProjectDir/osgi-client/src/main/resources/OSGI-INF/blueprint

ProjectDir/osgi-client/src/main/resources/OSGI-INF/blueprint 디렉터리 아래에서 원하는 텍스트 편집기를 사용하여 config.xml 을 생성하고 예 12.6. “서비스 가져오기를 위한 블루프린트 파일” 에서 XML 코드를 추가합니다.

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">

  <reference id="helloWorld"
        interface="org.fusesource.example.service.HelloWorldSvc"/>

  <bean id="client"
        class="org.fusesource.example.client.Client"
        init-method="init">
    <property name="helloWorldSvc" ref="helloWorld"/>
  </bean>

</blueprint>

여기서 reference 요소는 OSGi 레지스트리에서 HelloWorldSvc 유형의 서비스를 찾는 참조 관리자를 생성합니다. Cryo stat 요소는 Client 클래스의 인스턴스를 생성하고 서비스 참조를 8080 속성 helloWorldSvc 로 삽입합니다. 또한 init-method 속성은 빈 초기화 단계에서 Client.init() 메서드가 호출되도록 지정합니다(즉, 서비스 참조가 클라이언트사이에 삽입된 후 ).

ProjectDir/osgi-client/src/main/java/org/fusesource/example/client 디렉터리 아래의 텍스트 편집기를 사용하여 파일을 생성하고, Client.java 에서 Java 코드를 추가합니다. 예 12.7. “클라이언트 클래스”

package org.fusesource.example.client;

import org.fusesource.example.service.HelloWorldSvc;

public class Client {
    HelloWorldSvc helloWorldSvc;

    // Bean properties
    public HelloWorldSvc getHelloWorldSvc() {
        return helloWorldSvc;
    }

    public void setHelloWorldSvc(HelloWorldSvc helloWorldSvc) {
        this.helloWorldSvc = helloWorldSvc;
    }

    public void init() {
        System.out.println("OSGi client started.");
        if (helloWorldSvc != null) {
            System.out.println("Calling sayHello()");
            helloWorldSvc.sayHello();  // Invoke the OSGi service!
        }
    }

}

클라이언트 클래스는 삽입을 통해 Hello World 서비스에 대한 참조를 수신할 수 있는 helloWorldSvc 8080 속성에 대한 getter 및 setter 메서드를 정의합니다. init() 메서드는 속성 삽입 후 8080 초기화 단계에서 호출되므로 일반적으로 이 메서드 범위 내에서 Hello World 서비스를 호출할 수 있습니다.

osgi-client 프로젝트를 설치하고 실행하려면 다음 단계를 수행합니다.

Apache Camel은 Cryostat 언어를 사용하여 OSGi 서비스를 쉽게 호출할 수 있는 방법을 제공합니다. 이 기능은 Apache Camel 애플리케이션을 OSGi 컨테이너에 배포할 때마다 자동으로 사용할 수 있으며 특별한 구성이 필요하지 않습니다.

Apache Camel 경로가 OSGi 컨테이너에 배포되면 CamelContext 에서 빈 인스턴스를 해결하기 위해 레지스트리 체인을 자동으로 설정합니다. 레지스트리 체인은 OSGi 레지스트리와 블루프린트 레지스트리로 구성됩니다. 이제 특정 8080 클래스 또는 빈 인스턴스를 참조하려고 하면 레지스트리에서 다음과 같이 빈을 확인합니다.

단일 메서드인 getGreeting() 을 정의하는 다음 Java 인터페이스로 정의된 OSGi 서비스를 고려하십시오.

package org.fusesource.example.hello.boston;

public interface HelloBoston {
    public String getGreeting();
}

HelloBoston OSGi 서비스를 구현하는 번들을 정의할 때 다음 블루프린트 구성을 사용하여 서비스를 내보낼 수 있습니다.

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">

  <bean id="hello" class="org.fusesource.example.hello.boston.HelloBostonImpl"/>

  <service ref="hello" interface="org.fusesource.example.hello.boston.HelloBoston"/>

</blueprint>

여기서 HelloBoston 인터페이스는 HelloBostonImpl 클래스에서 구현되어 있지 않다고 가정합니다.

HelloBoston OSGi 서비스가 포함된 번들을 배포한 후 Java DSL을 사용하여 Apache Camel 애플리케이션에서 서비스를 호출할 수 있습니다. Java DSL에서는 다음과 같이 Cryostat 언어를 통해 OSGi 서비스를 호출합니다.

from("timer:foo?period=5000")
  .bean(org.fusesource.example.hello.boston.HelloBoston.class, "getGreeting")
  .log("The message contains: ${body}")

8080 명령에서 첫 번째 인수는 OSGi 인터페이스 또는 클래스이며 OSGi 서비스 번들에서 내보낸 인터페이스와 일치해야 합니다. 두 번째 인수는 호출하려는 8080 메서드의 이름입니다. Quarkus 명령 구문에 대한 자세한 내용은 Apache Camel Development Guide Cryostat Integration 을 참조하십시오.

XML DSL에서는 Cryostat 언어를 사용하여 HelloBoston OSGi 서비스를 호출할 수도 있지만 구문은 약간 다릅니다. XML DSL에서는 다음과 같이 method 요소를 사용하여 Cryostat 언어를 통해 OSGi 서비스를 호출합니다.

<beans ...>
  <camelContext xmlns="http://camel.apache.org/schema/spring">
    <route>
      <from uri="timer:foo?period=5000"/>
      <setBody>
          <method ref="org.fusesource.example.hello.boston.HelloBoston" method="getGreeting"/>
      </setBody>
      <log message="The message contains: ${body}"/>
    </route>
  </camelContext>
</beans>

파일 URL의 구문은 pathName입니다. 여기서 PathName 은 Classpath에서 사용할 수 있는 파일의 상대 또는 절대 경로 이름입니다. 제공된 PathName 은 Java의 기본 제공 파일 URL 처리기 에서 구문 분석합니다. 따라서 PathName 구문에는 Java 경로 이름의 일반적인 규칙이 적용됩니다. 특히 Windows에서는 각 백슬래시를 다른 백슬래시로 이스케이프하거나 슬래시로 교체해야 합니다.

예를 들어 Windows에서 경로 이름 C:\Projects\camel-bundle\target\foo-1.0-SNAPSHOT.jar 를 고려하십시오. 다음 예제에서는 Windows의 파일 URL에 대한 올바른 대안을 보여줍니다.

file:C:/Projects/camel-bundle/target/foo-1.0-SNAPSHOT.jar
file:C:\\Projects\\camel-bundle\\target\\foo-1.0-SNAPSHOT.jar

다음 예제에서는 Windows의 파일 URL에 대한 몇 가지 잘못된 대안을 보여줍니다.

file:C:\Projects\camel-bundle\target\foo-1.0-SNAPSHOT.jar        // WRONG!
file://C:/Projects/camel-bundle/target/foo-1.0-SNAPSHOT.jar      // WRONG!
file://C:\\Projects\\camel-bundle\\target\\foo-1.0-SNAPSHOT.jar  // WRONG!

HTTP URL에는 표준 구문, http:Host[:Port]/[Path][#AnchorName][?Query]. https 스키마를 사용하여 보안 HTTP URL을 지정할 수도 있습니다. 제공된 HTTP URL은 Java의 기본 제공 HTTP URL 처리기에서 구문 분석되므로 HTTP URL은 Java 애플리케이션의 일반적인 방식으로 작동합니다.

Maven을 사용하여 번들을 빌드하거나 Maven 리포지토리에서 특정 번들을 사용할 수 있는 경우 Mvn 처리기 스키마를 사용하여 번들을 찾을 수 있습니다.

Mvn URL 구문은 다음과 같습니다.

mvn:[repositoryUrl!]groupId/artifactId[/[version][/[packaging][/[classifier]]]]

여기서 repositoryUrl 은 선택적으로 Maven 리포지토리의 URL을 지정합니다. groupId,artifactId,version,packaging, classifier 는 Maven 아티팩트를 찾기 위한 표준 Maven 좌표입니다.

Mvn URL을 지정하는 경우 groupId 및 artifactId 좌표만 필요합니다. 다음 예제에서는 groupId,org.fusesource.example 및 artifactId,bundle-demo 를 사용하여 Maven 번들을 참조합니다.

mvn:org.fusesource.example/bundle-demo
mvn:org.fusesource.example/bundle-demo/1.1

첫 번째 예와 같이 버전이 생략되면 기본값은 LATEST 이며 사용 가능한 Maven 메타데이터를 기반으로 최신 버전으로 해석됩니다.

패키징 또는 버전 값을 지정하지 않고 분류자 값을 지정하려면 Mvn URL에 간격을 둘 수 있습니다. 마찬가지로 버전 값 없이 패키징 값을 지정하려면 다음을 수행합니다. 예를 들면 다음과 같습니다.

mvn:groupId/artifactId///classifier
mvn:groupId/artifactId/version//classifier
mvn:groupId/artifactId//packaging/classifier
mvn:groupId/artifactId//packaging

Mvn URL에 version 값을 지정하는 경우 간단한 버전 번호 대신 버전 범위(표준 Maven 버전 범위 구문을 사용하여)를 지정할 수 있습니다. 대괄호[ 및 ]-를 사용하여 포함 범위를 나타냅니다( 및 )- 독점 범위를 나타냅니다. 예를 들어 범위 [1.0.4,2.0) 는 1.0.4 Cryostat v < 2.0을 충족하는 모든 버전 v 와 일치합니다. 다음과 같이 Mvn URL에서 이 버전 범위를 사용할 수 있습니다.

mvn:org.fusesource.example/bundle-demo/[1.0.4,2.0)

Mvn URL을 처음 사용하기 전에 다음과 같이 Mvn URL 처리기 설정을 사용자 지정해야 할 수 있습니다.

Mvn URL 핸들러는 로컬 Maven 리포지토리에 대한 참조를 확인하고 원격 Maven 리포지토리 목록을 유지 관리합니다. Mvn URL을 확인할 때 처리기는 먼저 로컬 리포지토리를 검색한 다음 지정된 Maven Artifiact를 찾기 위해 원격 리포지토리를 검색합니다. Mvn URL을 해결하는 데 문제가 있는 경우 가장 먼저 수행해야 하는 작업은 처리기 설정을 확인하여 URL을 해결하기 위해 사용 중인 로컬 리포지토리와 원격 리포지토리를 확인하는 것입니다.

Mvn URL 설정을 확인하려면 콘솔에 다음 명령을 입력합니다.

JBossFuse:karaf@root> config:edit org.ops4j.pax.url.mvn
JBossFuse:karaf@root> config:proplist

config:edit 명령은 config 유틸리티의 초점을 org.ops4j.pax.url.mvn 영구 ID에 속하는 속성으로 전환합니다. config:proplist 명령은 현재 영구 ID에 대한 모든 속성 설정을 출력합니다. org.ops4j.pax.url.mvn 에 중점을 두고 다음과 유사한 목록이 표시됩니다.

   org.ops4j.pax.url.mvn.defaultRepositories = file:/path/to/JBossFuse/jboss-fuse-7.10.0.fuse-7_10_0-00010-redhat-00001/system@snapshots@id=karaf.system,file:/home/userid/.m2/repository@snapshots@id=local,file:/path/to/JBossFuse/jboss-fuse-7.10.0.fuse-7_10_0-00010-redhat-00001/local-repo@snapshots@id=karaf.local-repo,file:/path/to/JBossFuse/jboss-fuse-7.10.0.fuse-7_10_0-00010-redhat-00001/system@snapshots@id=child.karaf.system
   org.ops4j.pax.url.mvn.globalChecksumPolicy = warn
   org.ops4j.pax.url.mvn.globalUpdatePolicy = daily
   org.ops4j.pax.url.mvn.localRepository = /path/to/JBossFuse/jboss-fuse-7.10.0.fuse-7_10_0-00010-redhat-00001/data/repository
   org.ops4j.pax.url.mvn.repositories = http://repo1.maven.org/maven2@id=maven.central.repo, https://maven.repository.redhat.com/ga@id=redhat.ga.repo, https://maven.repository.redhat.com/earlyaccess/all@id=redhat.ea.repo, https://repository.jboss.org/nexus/content/groups/ea@id=fuseearlyaccess
   org.ops4j.pax.url.mvn.settings = /path/to/jboss-fuse-7.10.0.fuse-7_10_0-00010-redhat-00001/etc/maven-settings.xml
   org.ops4j.pax.url.mvn.useFallbackRepositories = false
   service.pid = org.ops4j.pax.url.mvn

where the localRepository setting shows the local repository location currently used by the handler and the repositories setting shows the remote repository list currently used by the handler.

Mvn URL 처리기의 속성 설정을 사용자 지정하려면 다음 구성 파일을 편집합니다.

InstallDir/etc/org.ops4j.pax.url.mvn.cfg

이 파일의 설정을 사용하면 로컬 Maven 리포지토리의 위치를 명시적으로 지정하고 Maven 리포지토리, Maven 프록시 서버 설정 등을 제거할 수 있습니다. 이러한 설정에 대한 자세한 내용은 설정 파일의 주석을 참조하십시오.

특히 로컬 Maven 리포지토리가 기본이 아닌 위치에 있는 경우 로컬로 빌드하는 Maven 아티팩트에 액세스하려면 명시적으로 구성해야 할 수 있습니다. org.ops4j.pax.url.mvn.cfg 구성 파일에서 org.ops4j.pax.url.mvn.localRepository 속성의 주석을 제거하고 로컬 Maven 리포지토리의 위치로 설정합니다. 예를 들면 다음과 같습니다.

# Path to the local maven repository which is used to avoid downloading
# artifacts when they already exist locally.
# The value of this property will be extracted from the settings.xml file
# above, or defaulted to:
#     System.getProperty( "user.home" ) + "/.m2/repository"
#
org.ops4j.pax.url.mvn.localRepository=file:E:/Data/.m2/repository

mvn URL 구문에 대한 자세한 내용은 원래 Pax URL Mvn Protocol 설명서를 참조하십시오.

번들로 패키지되지 않은 JAR 파일을 참조해야 하는 경우 Wrap URL 처리기를 사용하여 동적으로 변환할 수 있습니다. Wrap URL 핸들러의 구현은 Peter Krien의 오픈 소스 Bnd 유틸리티를 기반으로 합니다.

Wrap URL 구문에는 다음과 같은 구문이 있습니다.

wrap:locationURL[,instructionsURL][$instructions]

locationURL 은 JAR을 찾는 모든 URL일 수 있습니다(참조된 JAR이 번들로 포맷 되지 않음 ). 선택적 instructionsURL 은 번들 변환 수행 방법을 지정하는 Bnd 속성 파일을 참조합니다. 선택적 명령 은 번들 변환 수행 방법을 지정하는 Bnd 속성의 앰퍼샌드 및 delimited 목록입니다.

대부분의 경우 기본 Bnd 명령은 API JAR 파일을 래핑하는 데 적합합니다. 기본적으로 Wrap은 표 15.1. “JAR 트래핑을 위한 기본 지침” 와 같이 JAR의 META-INF/Manifest.mf 파일에 매니페스트 헤더를 추가합니다.

다음 Wrap URL은 Maven 리포지토리에서 commons-logging JAR의 버전 1.1을 찾고 기본 Bnd 속성을 사용하여 OSGi 번들로 변환합니다.

wrap:mvn:commons-logging/commons-logging/1.1

다음 Wrap URL은 파일의 Bnd 속성을 사용합니다. E:\Data\Examples\commons-logging-1.1.bnd:

wrap:mvn:commons-logging/commons-logging/1.1,file:E:/Data/Examples/commons-logging-1.1.bnd

다음 Wrap URL은 Bundle-SymbolicName 속성 및 Bundle-Version 속성을 명시적으로 지정합니다.

wrap:mvn:commons-logging/commons-logging/1.1$Bundle-SymbolicName=apache-comm-log&Bundle-Version=1.1

이전 URL을 명령줄 인수로 사용하는 경우 다음과 같이 명령줄에서 처리하지 못하도록 달러 기호 \$ 를 이스케이프해야 할 수 있습니다.

wrap:mvn:commons-logging/commons-logging/1.1\$Bundle-SymbolicName=apache-comm-log&Bundle-Version=1.1

랩 URL 처리기에 대한 자세한 내용은 다음 참조를 참조하십시오.

OSGi 컨테이너에 WAR 파일을 배포해야 하는 경우 여기에 설명된 대로 WAR URL 앞에 war: 를 추가하여 requisite 매니페스트 헤더를 WAR 파일에 자동으로 추가할 수 있습니다.

WAR URL은 다음 구문 중 하나를 사용하여 지정됩니다.

war:warURL
warref:instructionsURL

선전 체계를 사용하는 첫 번째 구문은 기본 지침을 사용하여 번들로 변환되는 WAR 파일을 지정합니다. warURL 은 WAR 파일을 찾는 모든 URL일 수 있습니다.

warref 스키마를 사용하는 두 번째 구문은 변환 명령(이 처리기에 고유한 일부 명령 포함)을 포함하는 Bnd 속성 파일인 instructionsURL 을 지정합니다. 이 구문에서 참조된 WAR 파일의 위치는 URL에 명시적으로 표시되지 않습니다. WAR 파일은 속성 파일의 (필수) WAR-URL 속성으로 대신 지정됩니다.

.bnd 명령 파일의 일부 속성은 다음과 같이 war URL 처리기에 고유합니다.

기본적으로 war URL 처리기는 표 15.2. “WAR 파일 래퍼에 대한 기본 지침” 에 표시된 대로 WAR의 META-INF/Manifest.mf 파일에 매니페스트 헤더를 추가합니다.

다음 war URL은 Maven 리포지토리에서 wicket-examples WAR의 버전 1.4.7을 찾고 기본 지침을 사용하여 OSGi 번들로 변환합니다.

war:mvn:org.apache.wicket/wicket-examples/1.4.7/war

다음 Wrap URL은 Web-ContextPath 를 명시적으로 지정합니다.

war:mvn:org.apache.wicket/wicket-examples/1.4.7/war?Web-ContextPath=wicket

다음 war URL은 wicket-examples-1.4.7.bnd 파일의 WAR-URL 속성에서 참조하는 WAR 파일을 변환한 다음 .bnd 파일의 다른 지침을 사용하여 WAR를 OSGi 번들로 변환합니다.

warref:file:E:/Data/Examples/wicket-examples-1.4.7.bnd

war URL 구문에 대한 자세한 내용은 원래 Pax URL war Protocol 설명서 를 참조하십시오.

PAXWEB-1255부터 리스너가 사용하는 XNIO 작업자 및 버퍼 풀의 구성을 변경할 수 있습니다. undertow.xml 템플릿에는 일부 IO 관련 매개변수의 기본값을 지정하는 섹션이 있습니다.

<!-- Only "default" worker and buffer-pool are supported and can be used to override the default values used by all listeners
    buffer-pool:
     - buffer-size defaults to:
        - when < 64MB of Xmx: 512
        - when < 128MB of Xmx: 1024
        - when >= 128MB of Xmx: 16K - 20
     - direct-buffers defaults to:
        - when < 64MB of Xmx: false
        - when >= 64MB of Xmx: true
    worker:
     - io-threads defaults to Math.max(Runtime.getRuntime().availableProcessors(), 2);
     - task-core-threads and task-max-threads default to io-threads * 8
-->

<!--
<subsystem xmlns="urn:jboss:domain:io:3.0">
    <buffer-pool name="default" buffer-size="16364" direct-buffers="true" />
    <worker name="default" io-threads="8" task-core-threads="64" task-max-threads="64" task-keepalive="60000" />
</subsystem>
-->

다음 buffer-pool 매개변수를 지정할 수 있습니다.

다음 작업자 매개변수를 지정할 수 있습니다.

Cryostat 스레드 풀과 해당 이름은 서비스별 또는 번들 기준으로 구성할 수 있으므로 Hawtio 콘솔에서 모니터링하고 디버깅을 보다 효율적으로 수행할 수 있습니다.

번들 블루프린트 구성 파일(일반적으로 Maven 프로젝트의 src/main/resources/OSGI-INF/blueprint 디렉터리에 저장됨)에서 다음 예와 같이 workerIOName 및 ThreadPool을 구성할 수 있습니다.

<httpu:engine-factory>
    <httpu:engine port="9001">
        <httpu:threadingParameters minThreads="99" maxThreads="777" workerIOThreads="8" workerIOName="WorkerIOTest"/>
    </httpu:engine>
</httpu:engine-factory>

다음의 threadingParameters 를 지정할 수 있습니다.

다음 작업자 매개변수를 지정할 수 있습니다.

콘솔에서 사용 가능한 명령 목록을 보려면 도움말 을 사용할 수 있습니다.

karaf@root()> help
bundle                            Enter the subshell
bundle:capabilities               Displays OSGi capabilities of a given bundles.
bundle:classes                    Displays a list of classes/resources contained in the bundle
bundle:diag                       Displays diagnostic information why a bundle is not Active
bundle:dynamic-import             Enables/disables dynamic-import for a given bundle.
bundle:find-class                 Locates a specified class in any deployed bundle
bundle:headers                    Displays OSGi headers of a given bundles.
bundle:id                         Gets the bundle ID.
...

간단한 설명과 함께 모든 명령 목록이 있습니다.

tab 키를 사용하여 모든 명령의 빠른 목록을 가져올 수 있습니다.

karaf@root()> Display all 294 possibilities? (y or n)
...

명령에는 범위와 이름이 있습니다. 예를 들어, 명령 feature:list 에는 범위가 있으며 list as name이 있습니다.

카프는 범위별로 명령을 "그룹"으로 합니다. 각 범위는 하위 쉘을 형성합니다.

정규화된 이름(scope:name)을 사용하여 명령을 직접 실행할 수 있습니다.

karaf@root()> feature:list
...

또는 하위 쉘을 입력하고 명령 컨텍스트를 하위 쉘로 입력합니다.

karaf@root()> feature
karaf@root(feature)> list

하위 쉘 이름(여기 기능)을 입력하여 직접 하위 쉘을 입력할 수 있습니다. 하위 쉘에서 다른 쉘로 직접 "switch"할 수 있습니다.

karaf@root()> feature
karaf@root(feature)> bundle
karaf@root(bundle)>

프롬프트에 () 사이의 현재 하위 쉘이 표시됩니다.

exit 명령은 상위 하위 쉘로 이동합니다.

karaf@root()> feature
karaf@root(feature)> exit
karaf@root()>

완료 모드는 tab 키의 동작과 help 명령을 정의합니다.

다음 세 가지 모드를 사용할 수 있습니다.

etc/org.apache.karaf.shell.cfg 파일의 completionMode 속성을 사용하여 기본 완료 모드를 정의할 수 있습니다. 기본적으로 다음을 수행할 수 있습니다.

completionMode = GLOBAL

shell:completion 명령을 사용하여 "오전기 중에"(카운트 쉘 콘솔을 사용하는 동안) 완료 모드를 변경할 수도 있습니다.

karaf@root()> shell:completion
GLOBAL
karaf@root()> shell:completion FIRST
karaf@root()> shell:completion
FIRST

shell:completion 은 사용된 현재 완료 모드에 대해 알려줍니다. 원하는 새 완료 모드를 제공할 수도 있습니다.

GLOBAL 완료 모드는 Karaf 4.0.0 (대부분의 전환 목적으로)의 기본 완료 모드입니다.

GLOBAL 모드는 실제로 하위 쉘을 사용하지 않습니다. 이전 Karaf 버전과 동일한 동작입니다.

tab 키를 입력하면 하위 쉘이 무엇이든 완료 시 모든 명령 및 모든 별칭이 표시됩니다.

karaf@root()> <TAB>
karaf@root()> Display all 273 possibilities? (y or n)
...
karaf@root()> feature
karaf@root(feature)> <TAB>
karaf@root(feature)> Display all 273 possibilities? (y or n)

첫 번째 완료 모드는 GLOBAL 완료 모드의 대안입니다.

루트 수준 하위 쉘에 tab 키를 입력하면 완료 시 모든 하위 쉘의 명령과 별칭(GLOBAL 모드)이 표시됩니다. 그러나 하위 쉘에 있는 경우 tab 키를 입력하면 완료에 현재 하위 쉘의 명령만 표시됩니다.

karaf@root()> shell:completion FIRST
karaf@root()> <TAB>
karaf@root()> Display all 273 possibilities? (y or n)
...
karaf@root()> feature
karaf@root(feature)> <TAB>
karaf@root(feature)>
info install list repo-add repo-list repo-remove uninstall version-list
karaf@root(feature)> exit
karaf@root()> log
karaf@root(log)> <TAB>
karaf@root(log)>
clear display exception-display get log set tail

SUBSHELL 완료 모드는 실제 하위 쉘 모드입니다.

루트 수준에서 Tab 키를 입력하면 완료에 하위 쉘 명령(하위 쉘로 이동)과 글로벌 별칭이 표시됩니다. 하위 쉘에 있으면 TAB 키를 입력하면 완료에 현재 하위 쉘의 명령이 표시됩니다.

karaf@root()> shell:completion SUBSHELL
karaf@root()> <TAB>
karaf@root()>
* bundle cl config dev feature help instance jaas kar la ld lde log log:list man package region service shell ssh system
karaf@root()> bundle
karaf@root(bundle)> <TAB>
karaf@root(bundle)>
capabilities classes diag dynamic-import find-class headers info install list refresh requirements resolve restart services start start-level stop
uninstall update watch
karaf@root(bundle)> exit
karaf@root()> camel
karaf@root(camel)> <TAB>
karaf@root(camel)>
backlog-tracer-dump backlog-tracer-info backlog-tracer-start backlog-tracer-stop context-info context-list context-start context-stop endpoint-list route-info route-list route-profile route-reset-stats
route-resume route-show route-start route-stop route-suspend

Karaf 콘솔은 환경과 같은 전체 Unix를 제공합니다.

karaf@root()> help feature:list
karaf@root()> man feature:list
karaf@root()> feature:list --help

DESCRIPTION
        feature:list

        Lists all existing features available from the defined repositories.

SYNTAX
        feature:list [options]

OPTIONS
        --help
                Display this help message
        -o, --ordered
                Display a list using alphabetical order
        -i, --installed
                Display a list of all installed features only
        --no-format
                Disable table rendered output

karaf@root()> alias "list-features-installed = { feature:list -i }"
karaf@root()> list-features-installed
Name       | Version | Required | State   | Repository     | Description
------------------------------------------------------------------------------------------------------------------------------
feature    | 4.0.0   | x        | Started | standard-4.0.0 | Features Support
shell      | 4.0.0   | x        | Started | standard-4.0.0 | Karaf Shell
deployer   | 4.0.0   | x        | Started | standard-4.0.0 | Karaf Deployer
bundle     | 4.0.0   | x        | Started | standard-4.0.0 | Provide Bundle support
config     | 4.0.0   | x        | Started | standard-4.0.0 | Provide OSGi ConfigAdmin support
diagnostic | 4.0.0   | x        | Started | standard-4.0.0 | Provide Diagnostic support
instance   | 4.0.0   | x        | Started | standard-4.0.0 | Provide Instance support
jaas       | 4.0.0   | x        | Started | standard-4.0.0 | Provide JAAS support
log        | 4.0.0   | x        | Started | standard-4.0.0 | Provide Log support
package    | 4.0.0   | x        | Started | standard-4.0.0 | Package commands and mbeans
service    | 4.0.0   | x        | Started | standard-4.0.0 | Provide Service support
system     | 4.0.0   | x        | Started | standard-4.0.0 | Provide System support
kar        | 4.0.0   | x        | Started | standard-4.0.0 | Provide KAR (KARaf archive) support
ssh        | 4.0.0   | x        | Started | standard-4.0.0 | Provide a SSHd server on Karaf
management | 4.0.0   | x        | Started | standard-4.0.0 | Provide a JMX MBeanServer and a set of MBeans in

ld = { log:display $args } ;
lde = { log:exception-display $args } ;
la = { bundle:list -t 0 $args } ;
ls = { service:list $args } ;
cl = { config:list "(service.pid=$args)" } ;
halt = { system:shutdown -h -f $args } ;
help = { *:help $args | more } ;
man = { help $args } ;
log:list = { log:get ALL } ;

karaf@root()> feature:list |grep -i war
pax-war                       | 4.1.4                            |          | Uninstalled | org.ops4j.pax.web-4.1.4  | Provide support of a full WebContainer
pax-war-tomcat                | 4.1.4                            |          | Uninstalled | org.ops4j.pax.web-4.1.4  |
war                           | 4.0.0                            |          | Uninstalled | standard-4.0.0           | Turn Karaf as a full WebContainer
blueprint-web                 | 4.0.0                            |          | Uninstalled | standard-4.0.0           | Provides an OSGI-aware Servlet ContextListener fo

karaf@root()> list = [1 2 3]; each ($list) { echo $it }
1
2
3

karaf@root()> a = 0 ; while { %((a+=1) <= 3) } { echo $a }
1
2
3

karaf@root()> list = ["Hello" world]; echo ($list get 0) ($list get 1)
Hello world

karaf@root()> $list class
...
ProtectionDomain     ProtectionDomain  null
 null
 <no principals>
 java.security.Permissions@6521c24e (
 ("java.security.AllPermission" "<all permissions>" "<all actions>")
)


Signers              null
SimpleName           ArrayList
TypeParameters       [E]

karaf@root()> ("hello world" toCharArray)
[h, e, l, l, o,  , w, o, r, l, d]

karaf@root()> ("hello world" toCharArray)[0]
Error executing command: [C cannot be cast to [Ljava.lang.Object;

karaf@root> shell:source script.txt
True!

foo = "foo"
if { $foo equals "foo" } {
  echo "True!"
}

if{ $foo equals "foo" } ...

karaf@root> shell:source script.txt
Error executing command: Cannot coerce echo "true!"() to any of []

Apache Karaf 콘솔은 RBAC(역할 기반 액세스 제어) 보안 메커니즘을 지원합니다. 즉, 콘솔에 연결된 사용자에 따라 사용자의 그룹 및 역할에 따라 일부 명령을 실행하거나 인수에 허용되는 값을 제한할 수 있습니다.

콘솔 보안은 이 사용자 가이드의 보안 섹션에 자세히 설명되어 있습니다.

애플리케이션을 프로비저닝하면 모든 모듈, 구성 및 전송 애플리케이션을 설치합니다.

기본적으로 OSGi 애플리케이션 배포를 지원합니다.

OSGi 애플리케이션은 OSGi 번들 세트입니다. OSGi 번들은 일반 Cryostat 파일로, 추가 메타데이터가 MANIFEST에 있습니다.

OSGi에서 번들은 다른 번들에 따라 달라질 수 있습니다. 따라서 OSGi 애플리케이션을 배포하려면 대부분의 경우 애플리케이션에 필요한 많은 다른 번들을 먼저 배포해야 합니다.

따라서 먼저 이러한 번들을 찾아서 번들을 설치해야 합니다. 다시 말하지만 이러한 "종속성" 번들은 자체 종속성을 충족하기 위해 다른 번들이 필요할 수 있습니다.

일반적으로 애플리케이션에는 구성이 필요합니다(사용자 가이드의 [구성 섹션|구성] 참조). 따라서 애플리케이션을 시작하기 전에 종속성 번들을 추가하거나 구성을 생성해야 합니다.

우리가 볼 수 있듯이 애플리케이션 프로비저닝은 매우 길고 단단할 수 있습니다.

Apache Karaf는 애플리케이션을 프로비저닝할 수 있는 간단하고 유연한 방법을 제공합니다.

Apache Karaf에서 애플리케이션 프로비저닝은 Apache Karaf "기능"입니다.

기능은 다음과 같이 애플리케이션을 설명합니다.

기능을 설치하면 Apache Karaf가 기능에 설명된 모든 리소스를 설치합니다. 즉, 기능에 설명된 모든 번들, 구성 및 종속성 기능을 자동으로 확인하고 설치합니다.

기능 확인자는 서비스 요구 사항을 확인하고 요구 사항과 일치하는 서비스를 제공하는 번들을 설치합니다. 기본 모드는 "새 스타일"에 대해서만 이 동작을 활성화합니다(기본적으로 스키마가 1.3.0) 이상인 기능 XML이 있습니다. "기존 스타일" 기능 리포지토리(카르프 2 또는 3)에는 적용되지 않습니다.

serviceRequirements 속성을 사용하여 etc/org.apache.karaf.features.cfg 파일에서 서비스 요구 사항 적용 모드를 변경할 수 있습니다.

serviceRequirements=default

가능한 값은 다음과 같습니다.

또한 기능은 요구 사항을 정의할 수도 있습니다. 이 경우 Karaf는 요구 사항을 충족하기 위해 기능을 제공하는 번들 또는 기능을 자동으로 추가할 수 있습니다.

기능에는 설치, 시작, 중지, 업데이트, 제거 등 전체 라이프사이클이 있습니다.

기능은 기능 XML 설명자에 설명되어 있습니다. 이 XML 파일에는 기능 집합에 대한 설명이 포함되어 있습니다.

기능 XML 설명자의 이름은 "features repository"입니다. 기능을 설치하려면 기능을 제공하는 기능 리포지토리를 등록해야 합니다(후에 설명된 대로 feature:repo-add 명령 또는 FeatureMBean 사용).

예를 들어 다음 XML 파일(또는 "features 리포지토리")은 feature1 및 feature2 기능을 설명합니다.

<features xmlns="http://karaf.apache.org/xmlns/features/v1.3.0">
  <feature name="feature1" version="1.0.0">
    <bundle>...</bundle>
    <bundle>...</bundle>
  </feature>
  <feature name="feature2" version="1.1.0">
    <feature>feature1</feature>
    <bundle>...</bundle>
  </feature>
</features>

XML 기능에는 스키마가 있습니다. 자세한 내용은 [Features XML Schema 섹션|provisioning-schema]을 참조하십시오. feature1 기능은 버전 1.0.0 에서 사용할 수 있으며 두 개의 번들을 포함합니다. < bundle/ > 요소에는 번들 아티팩트에 대한 URL이 포함되어 있습니다(자세한 내용은 [Artifacts 리포지토리 및 URL 섹션|urls] 참조). feature1 기능( feature:install 또는 later에 설명된 대로 FeatureMBean 사용)을 설치하는 경우 Apache Karaf는 설명된 두 개의 번들을 자동으로 설치합니다. feature2 기능은 버전 1.1.0 에서 사용할 수 있으며 feature1 기능과 번들에 대한 참조가 포함되어 있습니다. & lt;feature/& gt; 요소에는 기능 이름이 포함되어 있습니다. 특정 기능 버전은 <feature / > 요소의 version 속성을 사용하여 정의할 수 있습니다( <feature version="1.0.0">feature1</feature> ). version 속성을 지정하지 않으면 Apache Karaf가 사용 가능한 최신 버전을 설치합니다. feature2 기능(후에 설명된 대로 feature:install 또는 FeatureMBean 사용)을 설치하는 경우 Apache Karaf는 feature1 (아직 설치되지 않은 경우) 및 번들을 자동으로 설치합니다.

기능 리포지토리는 기능 XML 파일에 URL을 사용하여 등록됩니다.

기능 상태는 Apache Karaf 캐시( KARAF_DATA 폴더)에 저장됩니다. Apache Karaf를 다시 시작할 수 있으며 이전에 설치한 기능은 다시 시작한 후 계속 설치되고 사용할 수 있습니다. 새로 다시 시작하거나 Apache Karaf 캐시를 삭제하면( KARAF_DATA 폴더 삭제) 이전에 등록된 리포지토리와 설치된 모든 기능이 손실됩니다. 기능 리포지토리를 등록하고 기능을 다시 설치해야 합니다. 이 동작을 방지하려면 기능을 부팅 기능으로 지정할 수 있습니다.

일부 기능을 부팅 기능으로 설명할 수 있습니다. feature:install 또는 FeatureMBean을 사용하여 이전에 설치하지 않은 경우에도 Apache Karaf에 의해 부팅 기능이 자동으로 설치됩니다.

Apache Karaf 기능 구성은 etc/org.apache.karaf.features.cfg 구성 파일에 있습니다.

이 구성 파일에는 부팅 기능을 정의하는 데 사용할 두 가지 속성이 포함되어 있습니다.

동일한 기능을 설치하여 릴리스를 업데이트할 수 있습니다(동일한 SNAPSHOT 버전 또는 다른 버전).

기능 라이프사이클 덕분에 기능의 상태(시작, 중지 등)를 제어할 수 있습니다.

시뮬레이션을 사용하여 업데이트가 수행할 작업을 확인할 수도 있습니다.

기능에 정의된 번들은 etc/overrides.properties 파일을 사용하여 재정의할 수 있습니다. 파일의 각 행은 하나의 덮어쓰기를 정의합니다. 구문은 <bundle-uri>[;range="[min,max"] 지정된 번들이 재정의된 번들의 버전 및 범위가 일치하는 경우, 동일한 심볼릭 이름으로 기능 정의의 모든 번들을 재정의합니다. 범위를 지정하지 않으면 마이크로 버전 수준에서의 호환성이 가정됩니다.

예를 들어 재정의 mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5는 pax-logging-service 1.8.3을 덮어쓰지만 1.8.6 또는 1.7.0은 덮어씁니다.

기능은 다른 기능 집합에 따라 달라질 수 있습니다.

  <feature name="my-project" version="1.0.0">
    <feature>other</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>
  </feature>

my-project 기능이 설치되면 다른 기능도 자동으로 설치됩니다.

종속 기능에 대한 버전 범위를 정의할 수 있습니다.

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

범위에서 사용할 수 있는 가장 높은 버전의 기능이 설치됩니다.

단일 버전이 지정되면 범위가 열린 것으로 간주됩니다.

아무것도 지정하지 않으면 사용 가능한 최고가 설치됩니다.

정확한 버전을 지정하려면 [3.1,3.1] 과 같은 폐쇄 범위를 사용합니다.

기능 XML의 <config/ > 요소는 기능을 통해 구성을 생성 및/또는 채울 수 있습니다(구성 PID로 식별됨).

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

< config/ > 요소의 name 속성은 구성 PID에 해당합니다(자세한 내용은 [Configuration section|configuration] 참조).

기능 설치는 etc 폴더에 com.foo.bar.cfg 라는 파일을 삭제하는 것과 동일한 효과가 있습니다.

< config/&gt; 요소의 내용은 key=value 표준에 따라 속성 집합입니다.

< config/ > 요소를 사용하는 대신 기능은 < configfile/ > 요소를 지정할 수 있습니다.

<configfile finalname="/etc/myfile.cfg" override="false">URL</configfile>

Apache Karaf 구성 계층을 직접 조작하는 대신(< config/ > 요소를 사용할 때) < configfile/ > 요소는 URL로 지정된 파일을 직접 가져와서 최종 이름 특성에 지정된 위치에 파일을 복사합니다.

지정하지 않으면 위치는 KARAF_BASE 변수에서 상대적입니다. ${karaf.home}, ${karaf.base}, ${karaf.etc} 또는 시스템 속성과 같은 변수를 사용할 수도 있습니다.

예를 들면 다음과 같습니다.

<configfile finalname="${karaf.etc}/myfile.cfg" override="false">URL</configfile>

파일이 이미 원하는 위치에 이미 있고 기존 파일에 사용자 지정이 포함될 수 있으므로 구성 파일의 배포를 건너뜁니다. 이 동작은 재정의를 통해 true로 설정할 수 있습니다.

파일 URL은 Apache Karaf에서 지원하는 모든 URL입니다(자세한 내용은 사용자 가이드의 [Artifacts 리포지토리 및 URL|urls] 참조).

<requirement>osgi.ee;filter:=&quot;(&amp;(osgi.ee=JavaSE)(!(version&gt;=1.8)))&quot;</requirement>

배포 폴더에서 직접 파일을 삭제하여 기능 XML을 "hot deploy "할 수 있습니다.

Apache Karaf는 기능 배포자를 제공합니다.

배포 폴더에 기능 XML을 삭제하면 기능 배포자가 수행합니다. * features deployer는 features XML을 features repository로 등록합니다. * install 속성이 "auto"로 설정된 기능은 기능 배포자에 의해 자동으로 설치됩니다.

예를 들어 배포 폴더에 다음 XML을 삭제하면 feature1 및 feature2가 자동으로 설치되지만 feature3은 설치되지 않습니다.

<?xml version="1.0" encoding="UTF-8"?>
<features name="my-features" xmlns="http://karaf.apache.org/xmlns/features/v1.3.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.3.0 http://karaf.apache.org/xmlns/features/v1.3.0">

    <feature name="feature1" version="1.0" install="auto">
        ...
    </feature>

    <feature name="feature2" version="1.0" install="auto">
        ...
    </feature>

    <feature name="feature3" version="1.0">
        ...
    </feature>

</features>

Cryostat 계층에서는 기능 및 기능 리포지토리인 FeatureMBean을 관리하는 전용 권한이 있습니다.

FeatureMBean 오브젝트 이름은 org.apache.karaf:type=feature,name=* 입니다.

기본 모드 또는 2.1.3절. “서버 모드에서 런타임 시작” 에서 Red Hat Fuse 런타임을 시작하면 다른 Fuse 콘솔에서 SSH를 통해 액세스할 수 있는 원격 콘솔을 활성화합니다. 원격 콘솔은 로컬 콘솔의 모든 기능을 제공하며 원격 사용자가 컨테이너 및 내부에서 실행되는 서비스를 완전히 제어할 수 있습니다.

SSH 호스트 이름과 포트 번호는 INSTALL_DIR/etc/org.apache.karaf.shell.cfg 구성 파일에 구성됩니다. 원격 액세스용 포트 변경 는 8102로 사용되는 포트를 변경하는 샘플 구성을 보여줍니다.

sshPort=8102
sshHost=0.0.0.0

Maven 빌드 시스템의 가장 중요한 원칙 중 하나는 Maven 프로젝트의 모든 파일에 대한 표준 위치가 있다는 것입니다. 이 원칙에는 몇 가지 장점이 있습니다. 한 가지 장점은 Maven 프로젝트에는 일반적으로 동일한 디렉터리 레이아웃이 있어 프로젝트에서 파일을 쉽게 찾을 수 있다는 것입니다. 또 다른 장점은 Maven과 통합된 다양한 툴이 초기 구성이 거의 필요하지 않다는 것입니다. 예를 들어 Java 컴파일러는 src/main/java 아래에 있는 모든 소스 파일을 컴파일하고 결과를 대상/클래스 에 배치해야 함을 알고 있습니다.

예 18.1. “표준 Maven 디렉터리 레이아웃” OSGi 번들 프로젝트 빌드와 관련된 표준 Maven 디렉터리 레이아웃의 요소를 보여줍니다. 또한 블루프린트 구성 파일(MM에 의해 정의되지 않음 )의 표준 위치도 표시됩니다.

ProjectDir/
    pom.xml
    src/
        main/
            java/
                ...
            resources/
                META-INF/

                OSGI-INF/
                    blueprint/
                        *.xml
        test/
            java/
            resources/
    target/
        ...

pom.xml 파일은 현재 프로젝트를 빌드하는 방법에 대한 완전한 설명이 포함된 현재 프로젝트의 POM(Project Object Model)입니다. pom.xml 파일은 완전히 자체 포함 될 수 있지만 상위 POM 파일에서 설정을 가져올 수 있습니다.

프로젝트를 빌드한 후 생성된 JAR 파일의 다음 위치에 pom.xml 파일의 사본이 자동으로 포함됩니다.

META-INF/maven/groupId/artifactId/pom.xml

src/ 디렉터리에는 프로젝트를 개발하는 동안 작업할 모든 코드와 리소스 파일이 포함되어 있습니다.

target/ 디렉터리에는 빌드 결과(일반적으로 JAR 파일)와 빌드 중에 생성된 모든 중간 파일이 포함됩니다. 예를 들어 빌드를 수행한 후 target/classes/ 디렉터리에는 리소스 파일의 복사본과 컴파일된 Java 클래스가 포함됩니다.

src/main/ 디렉터리에는 아티팩트를 빌드하는 데 필요한 모든 코드와 리소스가 포함되어 있습니다.

src/test/ 디렉터리에는 컴파일된 아티팩트에 대해 단위 테스트를 실행하기 위한 모든 코드와 리소스가 포함되어 있습니다.

각 java / 하위 디렉터리에는 표준 Java 디렉터리 레이아웃이 있는 Java 소스 코드(*.java 파일)가 포함되어 있습니다(즉, 디렉터리 경로 이름이 . 문자 대신 Java 패키지 이름을 미러링하는 경우). src/main/java/ 디렉터리에는 번들 소스 코드가 포함되어 있고 src/test/java/ 디렉터리에는 단위 테스트 소스 코드가 포함되어 있습니다.

번들에 포함할 구성 파일, 데이터 파일 또는 Java 속성이 있는 경우 src/main/resources/ 디렉터리에 배치해야 합니다. src/main/resources/ 아래의 파일 및 디렉터리는 Maven 빌드 프로세스에서 생성되는 JAR 파일의 루트로 복사됩니다.

src/test/resources/ 아래의 파일은 테스트 단계에서만 사용되며 생성된 JAR 파일에 복사 되지 않습니다.

OSGi R4.2는 블루프린트 컨테이너를 정의합니다. Red Hat Fuse는 블루프린트 컨테이너를 기본적으로 지원하므로 블루프린트 구성 파일인 OSGI-INF/blueprint/*.xml 을 프로젝트에 포함할 수 있습니다. 블루프린트 컨테이너에 대한 자세한 내용은 12장. OSGi Services 에서 참조하십시오.

log:clear 명령은 로그 항목을 지웁니다.

log:display 명령은 로그 항목을 표시합니다.

기본적으로 rootLogger 의 로그 항목을 표시합니다.

karaf@root()> log:display
2015-07-01 19:12:46,208 | INFO  | FelixStartLevel  | SecurityUtils                    | 16 - org.apache.sshd.core - 0.12.0 | BouncyCastle not registered, using the default JCE provider
2015-07-01 19:12:47,368 | INFO  | FelixStartLevel  | core                             | 68 - org.apache.aries.jmx.core - 1.1.1 | Starting JMX OSGi agent

로거 인수를 사용하여 특정 로거의 로그 항목을 표시할 수도 있습니다.

karaf@root()> log:display ssh
2015-07-01 19:12:46,208 | INFO  | FelixStartLevel  | SecurityUtils                    | 16 - org.apache.sshd.core - 0.12.0 | BouncyCastle not registered, using the default JCE provider

기본적으로 모든 로그 항목이 표시됩니다. Apache Karaf 컨테이너가 장기 실행 중인 경우 매우 길 수 있습니다. n 옵션을 사용하여 표시할 항목 수를 제한할 수 있습니다.

karaf@root()> log:display -n 5
2015-07-01 06:53:24,143 | INFO  | JMX OSGi Agent   | core                             | 68 - org.apache.aries.jmx.core - 1.1.1 | Registering org.osgi.jmx.framework.BundleStateMBean to MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@27cc75cb with name osgi.core:type=bundleState,version=1.7,framework=org.apache.felix.framework,uuid=5335370f-9dee-449f-9b1c-cabe74432ed1
2015-07-01 06:53:24,150 | INFO  | JMX OSGi Agent   | core                             | 68 - org.apache.aries.jmx.core - 1.1.1 | Registering org.osgi.jmx.framework.PackageStateMBean to MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@27cc75cb with name osgi.core:type=packageState,version=1.5,framework=org.apache.felix.framework,uuid=5335370f-9dee-449f-9b1c-cabe74432ed1
2015-07-01 06:53:24,150 | INFO  | JMX OSGi Agent   | core                             | 68 - org.apache.aries.jmx.core - 1.1.1 | Registering org.osgi.jmx.framework.ServiceStateMBean to MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@27cc75cb with name osgi.core:type=serviceState,version=1.7,framework=org.apache.felix.framework,uuid=5335370f-9dee-449f-9b1c-cabe74432ed1
2015-07-01 06:53:24,152 | INFO  | JMX OSGi Agent   | core                             | 68 - org.apache.aries.jmx.core - 1.1.1 | Registering org.osgi.jmx.framework.wiring.BundleWiringStateMBean to MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@27cc75cb with name osgi.core:type=wiringState,version=1.1,framework=org.apache.felix.framework,uuid=5335370f-9dee-449f-9b1c-cabe74432ed1
2015-07-01 06:53:24,501 | INFO  | FelixStartLevel  | RegionsPersistenceImpl           | 78 - org.apache.karaf.region.persist - 4.0.0 | Loading region digraph persistence

etc/org.apache.karaf.log.cfg 파일의 size 속성을 사용하여 저장 및 유지되는 항목 수를 제한할 수도 있습니다.

#
# The number of log statements to be displayed using log:display. It also defines the number
# of lines searched for exceptions using log:display exception. You can override this value
# at runtime using -n in log:display.
#
size = 500

기본적으로 각 로그 수준은 다른 색상으로 표시됩니다. ERROR/FATAL은 빨간색, DEBUG in purple, INFO in cyan 등입니다. no-color 옵션을 사용하여 색상을 비활성화할 수 있습니다.

로그 항목 형식 패턴은 etc/org.ops4j.pax.logging.cfg 파일에 정의된 변환 패턴을 사용하지 않습니다. 기본적으로 etc/org.apache.karaf.log.cfg 에 정의된 pattern 속성을 사용합니다.

#
# The pattern used to format the log statement when using log:display. This pattern is according
# to the log4j2 layout. You can override this parameter at runtime using log:display with -p.
#
pattern = %d{ISO8601} | %-5.5p | %-16.16t | %-32.32c{1} | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n

또한 -p 옵션을 사용하여 동적으로(한 번 실행) 패턴을 변경할 수도 있습니다.

karaf@root()> log:display -p "\%d - \%c - \%m\%n"
2015-07-01 07:01:58,007 - org.apache.sshd.common.util.SecurityUtils - BouncyCastle not registered, using the default JCE provider
2015-07-01 07:01:58,725 - org.apache.aries.jmx.core - Starting JMX OSGi agent
2015-07-01 07:01:58,744 - org.apache.aries.jmx.core - Registering MBean with ObjectName [osgi.compendium:service=cm,version=1.3,framework=org.apache.felix.framework,uuid=6361fc65-8df4-4886-b0a6-479df2d61c83] for service with service.id [13]
2015-07-01 07:01:58,747 - org.apache.aries.jmx.core - Registering org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@27cc75cb with name osgi.compendium:service=cm,version=1.3,framework=org.apache.felix.framework,uuid=6361fc65-8df4-4886-b0a6-479df2d61c83

패턴은 날짜에 %d, 클래스의 %c, 로그 메시지의 경우 %m과 같은 키워드를 사용할 수 있는 일반 Log4j2 패턴입니다.

log:exception-display 명령은 마지막으로 발생한 예외를 표시합니다.

log:display 명령과 마찬가지로 log:exception-display 명령은 기본적으로 rootLogger 를 사용하지만 logger 인수를 사용하여 로거를 지정할 수 있습니다.

log:get 명령은 로거의 현재 로그 수준을 표시합니다.

기본적으로 표시된 로그 수준은 루트 로거에서 가져온 것입니다.

karaf@root()> log:get
Logger                              │ Level
────────────────────────────────────┼──────
ROOT                                │ INFO
org.apache.aries.spifly             │ WARN
org.apache.karaf.jaas.modules.audit │ INFO
org.apache.sshd                     │ INFO

로거 인수를 사용하여 특정 로거 를 지정할 수 있습니다.

karaf@root()> log:get ssh
INFO

logger 인수는 ALL 키워드를 사용하여 모든 로거의 로그 수준을 목록으로 표시합니다.

예를 들어 etc/org.ops4j.pax.logging.cfg 파일에서 다음과 같이 자체 로거를 정의했습니다.

log4j2.logger.my.name = MyLogger
log4j2.logger.my.level = DEBUG

해당 로그 수준으로 로거 목록을 확인할 수 있습니다.

karaf@root()> log:get ALL
Logger                              │ Level
────────────────────────────────────┼──────
MyLogger                            │ DEBUG
ROOT                                │ INFO
org.apache.aries.spifly             │ WARN
org.apache.karaf.jaas.modules.audit │ INFO
org.apache.sshd                     │ INFO

log:list 명령은 log:get ALL 의 별칭입니다.

log:log 명령을 사용하면 로그에 메시지를 수동으로 추가할 수 있습니다. Apache Karaf 스크립트를 만들 때 매우 유용합니다.

karaf@root()> log:log "Hello World"
karaf@root()> log:display
12:55:21.706 INFO [pipe-log:log "Hello World"] Hello World

기본적으로 로그 수준은 INFO이지만 -l 옵션을 사용하여 다른 로그 수준을 지정할 수 있습니다.

karaf@root()> log:clear
karaf@root()> log:log -l ERROR "Hello World"
karaf@root()> log:display
12:55:41.460 ERROR [pipe-log:log "Hello World"] Hello World

log:set 명령은 로거의 로그 수준을 설정합니다.

기본적으로 rootLogger 의 로그 수준을 변경합니다.

karaf@root()> log:set DEBUG
karaf@root()> log:get
Logger                              │ Level
────────────────────────────────────┼──────
ROOT                                │ DEBUG
...

수준 1 뒤에 로거 인수를 사용하여 특정 로거 를 지정할 수 있습니다.

karaf@root()> log:set INFO my.logger
karaf@root()> log:get my.logger
Logger    | Level
-----------------
my.logger | INFO

level 인수는 Log4j2 로그 수준인 TRACE, DEBUG, INFO, WARN, ERROR, FATAL을 허용합니다.

또한 DEFAULT 특수 키워드도 허용합니다.

DEFAULT 키워드의 목적은 로거 상위 수준의 로거를 사용하기 위해 로거의 현재 수준을 삭제하는 것입니다(및 수준만 수준만, appender와 같은 다른 속성은 삭제되지 않습니다).

예를 들어 다음 로거( etc/org.ops4j.pax.logging.cfg 파일)를 정의했습니다.

rootLogger=INFO,out,osgi:*
my.logger=INFO,appender1
my.logger.custom=DEBUG,appender2

my.logger.custom 로거의 수준을 변경할 수 있습니다.

karaf@root()> log:set INFO my.logger.custom

이제 다음을 수행합니다.

rootLogger=INFO,out,osgi:*
my.logger=INFO,appender1
my.logger.custom=INFO,appender2

my.logger.custom 로거에서 DEFAULT 키워드를 사용하여 수준을 제거할 수 있습니다.

karaf@root()> log:set DEFAULT my.logger.custom

이제 다음을 수행합니다.

rootLogger=INFO,out,osgi:*
my.logger=INFO,appender1
my.logger.custom=appender2

즉, 런타임에 my.logger.custom 로거는 상위 my.logger의 수준을 사용하므로 INFO 임을 의미합니다.

이제 my.logger 로거와 함께 DEFAULT 키워드를 사용하는 경우:

karaf@root()> log:set DEFAULT my.logger

Red Hat은 다음과 같습니다.

rootLogger=INFO,out,osgi:*
my.logger=appender1
my.logger.custom=appender2

따라서 my.logger.custom 및 my.logger 모두 상위 rootLogger 의 로그 수준을 사용합니다.

rootLogger 와 함께 DEFAULT 키워드를 사용할 수 없으며 부모가 없습니다.

log:tail 은 log:display 와 정확히 동일하지만 로그 항목을 지속적으로 표시합니다.

log:display 명령과 동일한 옵션 및 인수를 사용할 수 있습니다.

기본적으로 rootLogger 의 항목을 표시합니다.

karaf@root()> log:tail
2015-07-01 07:40:28,152 | INFO  | FelixStartLevel  | SecurityUtils                    | 16 - org.apache.sshd.core - 0.9.0 | BouncyCastle not registered, using the default JCE provider
2015-07-01 07:40:28,909 | INFO  | FelixStartLevel  | core                             | 68 - org.apache.aries.jmx.core - 1.1.1 | Starting JMX OSGi agent
2015-07-01 07:40:28,928 | INFO  | FelixStartLevel  | core                             | 68 - org.apache.aries.jmx.core - 1.1.1 | Registering MBean with ObjectName [osgi.compendium:service=cm,version=1.3,framework=org.apache.felix.framework,uuid=b44a44b7-41cd-498f-936d-3b12d7aafa7b] for service with service.id [13]
2015-07-01 07:40:28,936 | INFO  | JMX OSGi Agent   | core                             | 68 - org.apache.aries.jmx.core - 1.1.1 | Registering org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@27cc75cb with name osgi.compendium:service=cm,version=1.3,framework=org.apache.felix.framework,uuid=b44a44b7-41cd-498f-936d-3b12d7aafa7b

log:tail 명령을 종료하려면 CTRL-C를 입력합니다.

Fuse-Karaf는 Log4j2 sift appender의 샘플(기본적으로 설명) 구성과 $FUSE_HOME/etc/org.ops4j.pax.logging.cfg 파일에서 이 appender를 사용하는 로거를 제공합니다.

# Sift appender
log4j2.appender.mdc.type = Routing
log4j2.appender.mdc.name = SiftAppender
log4j2.appender.mdc.routes.type = Routes
# see: http://logging.apache.org/log4j/2.x/manual/appenders.html#Routes
log4j2.appender.mdc.routes.pattern = $\\{ctx:bundle.name}
log4j2.appender.mdc.routes.sift.type = Route
log4j2.appender.mdc.routes.sift.appender.type = RollingRandomAccessFile
log4j2.appender.mdc.routes.sift.appender.name = RollingFile
log4j2.appender.mdc.routes.sift.appender.fileName = ${karaf.data}/log/sift-$\\{ctx:bundle.name}.log
log4j2.appender.mdc.routes.sift.appender.filePattern = ${karaf.data}/log/sift-$\\{ctx:bundle.name}-%i.log.gz
log4j2.appender.mdc.routes.sift.appender.append = true
log4j2.appender.mdc.routes.sift.appender.layout.type = PatternLayout
log4j2.appender.mdc.routes.sift.appender.layout.pattern = ${log4j2.pattern}
log4j2.appender.mdc.routes.sift.appender.policies.type = Policies
log4j2.appender.mdc.routes.sift.appender.policies.size.type = SizeBasedTriggeringPolicy
log4j2.appender.mdc.routes.sift.appender.policies.size.size = 16MB
log4j2.appender.mdc.routes.sift.appender.strategy.type = DefaultRolloverStrategy
log4j2.appender.mdc.routes.sift.appender.strategy.max = 20
...
# sample logger using Sift appender
#log4j2.logger.example.name = org.apache.camel
#log4j2.logger.example.level = INFO
#log4j2.logger.example.appenderRef.SiftAppender.ref = SiftAppender

구성은 http://logging.apache.org/log4j/2.x/manual/appenders.html#RoutingAppender에 설명되어 있습니다.

SIFT/Routing appender의 pattern 속성은 로깅의 대상 위치를 구분하는 데 사용할 수 있는 것입니다.

다음은 다양한 조회를 사용할 수 있으며 여기에 설명되어 있습니다. http://logging.apache.org/log4j/2.x/manual/lookups.html

가장 중요한 조회는 ThreadContext 맵(.k.a)에서 값(keys)을 조회하는 ctx 입니다. MDC).

Fuse Karaf에서 제공하는 기본 구성은 ctx:bundle.name을 패턴으로 사용합니다. 즉, 다음과 같습니다.

lookup bundle.name key in MDC

bundle. 접두사가 지정된 키는 pax-logging 자체에서 제공하며 다음 3가지 값 중에서 선택할 수 있습니다.

그러나 다음을 사용하여 MDC 지원을 통해 Camel 컨텍스트가 생성되는 경우(파란트 XML DSL).

<camelContext id="my-context" xmlns="http://camel.apache.org/schema/blueprint" useMDCLogging="true">

MDC/ThreadContext에서 사용할 수 있는 더 많은 키가 있으며 SIFT appender 구성에서 패턴으로 사용할 수 있습니다.

https://people.apache.org/~dkulp/camel/mdc-logging.html에서 참조하십시오.

예를 들어 로깅 대상 파일을 Camel의 경로 ID로 구분하려면 다음을 사용하십시오.

log4j2.appender.mdc.routes.pattern = $\\{ctx:camel.routeId}
...
log4j2.appender.mdc.routes.sift.appender.fileName = ${karaf.data}/log/sift-$\\{ctx:camel.routeId}.log
log4j2.appender.mdc.routes.sift.appender.filePattern = ${karaf.data}/log/sift-$\\{ctx:camel.routeId}-%i.log.gz

한 가지 더 - 추가 구성만으로는 충분하지 않습니다. 일부 로거에 연결해야 합니다. 다시 한 번 샘플 구성에는 다음이 포함됩니다.

# sample logger using Sift appender
#log4j2.logger.example.name = org.apache.camel
#log4j2.logger.example.level = INFO
#log4j2.logger.example.appenderRef.SiftAppender.ref = SiftAppender

( log4j2.logger.example.appenderRef.SiftAppender.ref 속성의 SiftAppender 값은 appender 구성의 log4j2.appender.mdc.name 값과 일치해야 합니다).

여기서 org.apache.camel은 로거 이름(또는 카테고리 이름)입니다. 이는 Camel의 로그에 사용되는 끝점과 정확히 동일합니다. If you have (in Camel route):

<to uri="log:org.apache.camel" />

로깅이 작동했습니다.

다른 작업 구성은 다음과 같습니다.

<to uri="log:my-special-logger" />

및 다음을 수행합니다.

log4j2.logger.example.name = my-special-logger
log4j2.logger.example.level = DEBUG
log4j2.logger.example.appenderRef.SiftAppender.ref = SiftAppender

appender에 필터를 적용할 수 있습니다. 필터는 각 로그 이벤트를 평가하고 로그로 보낼지 여부를 결정합니다.

Log4j2는 필터를 사용할 준비가 되어 있습니다.

중첩된 appender는 다른 appender를 "내부"하는 특수한 종류의 appender입니다. 이를 통해 appender 체인 사이에 일종의 "라우팅"을 생성할 수 있습니다.

가장 많이 사용되는 "nested compliant" appender는 다음과 같습니다.

이러한 종류의 appender는 appender 정의에서 appenders 속성을 허용합니다.

log4j2.appender.[appender-name].appenders=[comma-separated-list-of-appender-names]

예를 들어 async 라는 Async 및 비동기적으로 로그 이벤트를 JMS appender에 디스패치하는 AsyncAppender를 생성할 수 있습니다.

log4j2.appender.async=org.apache.log4j2.AsyncAppender
log4j2.appender.async.appenders=jms

log4j2.appender.jms=org.apache.log4j2.net.JMSAppender
...

경우에 따라 appender가 실패할 수 있습니다. 예를 들어 RollingFileAppender 는 파일 시스템에 작성하려고 하지만 파일 시스템이 가득거나 JMS appender가 메시지를 전송하려고 하지만 JMS 브로커를 사용할 수 없습니다.

로그 appender가 실패하는지 확인하는 것이 중요하므로 로깅이 중요할 수 있습니다.

각 로그 appender는 오류 처리기에 오류 처리를 위임하여 appender 오류에 대응할 수 있는 기회를 제공합니다.

appender 정의 자체에서 errorhandler 속성을 사용하여 각 appender에 사용할 오류 처리기 를 정의할 수 있습니다.

log4j2.appender.[appender-name].errorhandler=[error-handler-class]
log4j2.appender.[appender-name].errorhandler.root-ref=[true|false]
log4j2.appender.[appender-name].errorhandler.logger-ref=[logger-ref]
log4j2.appender.[appender-name].errorhandler.appender-ref=[appender-ref]

라우팅 부록 은 MDC(Mapped Diagnostic Context) 속성을 기반으로 로그 이벤트를 분할할 수 있는 OSGi 지향 appender입니다.

MDC를 사용하면 다양한 로그 이벤트 소스를 구분할 수 있습니다.

라우팅 appender는 기본적으로 OSGi 지향 MDC 속성을 제공합니다.

이러한 MDC 속성을 사용하여 번들당 로그 파일을 생성할 수 있습니다.

log4j2.appender.routing.type = Routing
log4j2.appender.routing.name = Routing
log4j2.appender.routing.routes.type = Routes
log4j2.appender.routing.routes.pattern = $$\\{ctx:bundle.name\\}
log4j2.appender.routing.routes.bundle.type = Route
log4j2.appender.routing.routes.bundle.appender.type = RollingRandomAccessFile
log4j2.appender.routing.routes.bundle.appender.name = Bundle-$\\{ctx:bundle.name\}
log4j2.appender.routing.routes.bundle.appender.fileName = ${karaf.data}/log/bundle-$\\{ctx:bundle.name\\}.log
log4j2.appender.routing.routes.bundle.appender.filePattern = ${karaf.data}/log/bundle-$\\{ctx:bundle.name\\}.log.%d{yyyy-MM-dd}
log4j2.appender.routing.routes.bundle.appender.append = true
log4j2.appender.routing.routes.bundle.appender.layout.type = PatternLayout
log4j2.appender.routing.routes.bundle.appender.policies.type = Policies
log4j2.appender.routing.routes.bundle.appender.policies.time.type = TimeBasedTriggeringPolicy
log4j2.appender.routing.routes.bundle.appender.strategy.type = DefaultRolloverStrategy
log4j2.appender.routing.routes.bundle.appender.strategy.max = 31

log4j2.rootLogger.appenderRef.Routing.ref = Routing

기본적으로 Apache Karaf는 특정 스택 추적 렌더러를 제공하여 일부 OSGi 특정 정보를 추가합니다.

스택 추적에서 예외를 throw하는 클래스 외에도 각 스택 추적 라인 끝에 [id:name:version] 패턴을 찾을 수 있습니다.

문제의 원인을 진단하는 것이 매우 유용합니다.

예를 들어 다음 IllegalArgumentException 스택 추적에서는 예외 소스에 대한 OSGi 세부 정보를 볼 수 있습니다.

java.lang.IllegalArgumentException: Command not found:  *:foo
	at org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:225)[21:org.apache.karaf.shell.console:4.0.0]
	at org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[21:org.apache.karaf.shell.console:4.0.0]
	at org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[21:org.apache.karaf.shell.console:4.0.0]
	at org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[21:org.apache.karaf.shell.console:4.0.0]
	at org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[21:org.apache.karaf.shell.console:4.0.0]
	at org.apache.karaf.shell.console.jline.Console.run(Console.java:169)[21:org.apache.karaf.shell.console:4.0.0]
	at java.lang.Thread.run(Thread.java:637)[:1.7.0_21]

Apache Karaf에서 고유한 appender를 사용할 수 있습니다.

가장 쉬운 방법은 appender를 OSGi 번들로 패키지하고 org.ops4j.pax.logging.pax-logging-service 번들의 조각으로 연결하는 것입니다.

예를 들어 MyAppender 를 만듭니다.

public class MyAppender extends AppenderSkeleton {
...
}

다음과 같이 MANIFEST가 포함된 OSGi 번들로 컴파일하고 패키징합니다.

Manifest:
Bundle-SymbolicName: org.mydomain.myappender
Fragment-Host: org.ops4j.pax.logging.pax-logging-service
...

Apache Karaf 시스템 폴더에 번들을 복사합니다. 시스템 폴더는 표준 Maven 디렉터리 레이아웃인 groupId/artifactId/version을 사용합니다.

etc/startup.properties 구성 파일에서 pax-logging-service 번들 전에 목록에 번들을 정의합니다.

시스템 번들을 다시 로드하려면 새로 실행( 데이터 폴더 수행)을 사용하여 Apache Karaf를 다시 시작해야 합니다. 이제 etc/org.ops4j.pax.logging.cfg 구성 파일에서 직접 appender를 사용할 수 있습니다.

지금까지 본 것처럼 Apache Karaf는 PropertiesLoginModule을 사용합니다.

이 로그인 모듈은 etc/users.properties 파일을 사용자, 그룹, 역할 및 암호의 스토리지로 사용합니다.

초기 etc/users.properties 파일에는 다음이 포함됩니다.

################################################################################
#
#    Licensed to the Apache Software Foundation (ASF) under one or more
#    contributor license agreements.  See the NOTICE file distributed with
#    this work for additional information regarding copyright ownership.
#    The ASF licenses this file to You under the Apache License, Version 2.0
#    (the "License"); you may not use this file except in compliance with
#    the License.  You may obtain a copy of the License at
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
#    Unless required by applicable law or agreed to in writing, software
#    distributed under the License is distributed on an "AS IS" BASIS,
#    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#    See the License for the specific language governing permissions and
#    limitations under the License.
#
################################################################################

#
# This file contains the users, groups, and roles.
# Each line has to be of the format:
#
# USER=PASSWORD,ROLE1,ROLE2,...
# USER=PASSWORD,_g_:GROUP,...
# _g_\:GROUP=ROLE1,ROLE2,...
#
# All users, grousp, and roles entered in this file are available after Karaf startup
# and modifiable via the JAAS command group. These users reside in a JAAS domain
# with the name "karaf".
#
karaf = karaf,_g_:admingroup
_g_\:admingroup = group,admin,manager,viewer

이 파일에서는 기본적으로 한 명의 사용자가 있습니다. karaf. 기본 암호는 karaf 입니다.

karaf 사용자는 하나의 그룹인 admingroup 의 멤버입니다.

그룹은 항상 g: 접두사가 지정됩니다. 이 접두사가 없는 항목은 사용자입니다.

그룹은 역할 세트를 정의합니다. 기본적으로 admin group 은 그룹 ,admin,manager, viewer 역할을 정의합니다.

즉, karaf 사용자는 admingroup 에서 정의한 역할을 갖습니다.

karaf@root()> jaas:realm-list
Index | Realm Name | Login Module Class Name
-----------------------------------------------------------------------------------
1     | karaf      | org.apache.karaf.jaas.modules.properties.PropertiesLoginModule
2     | karaf      | org.apache.karaf.jaas.modules.publickey.PublickeyLoginModule

karaf@root()> jaas:realm-manage --index 1

karaf@root()> jaas:realm-manage --realm karaf --module org.apache.karaf.jaas.modules.properties.PropertiesLoginModule

karaf@root()> jaas:user-list
User Name | Group      | Role
--------------------------------
karaf     | admingroup | admin
karaf     | admingroup | manager
karaf     | admingroup | viewer

karaf@root()> jaas:user-add foo bar

karaf@root()> jaas:update
karaf@root()> jaas:realm-manage --index 1
karaf@root()> jaas:user-list
User Name | Group      | Role
--------------------------------
karaf     | admingroup | admin
karaf     | admingroup | manager
karaf     | admingroup | viewer
foo       |            |

karaf@root()> jaas:user-delete foo

karaf@root()> jaas:update
karaf@root()> jaas:realm-manage --index 1
karaf@root()> jaas:user-list
User Name | Group      | Role
--------------------------------
karaf     | admingroup | admin
karaf     | admingroup | manager
karaf     | admingroup | viewer

karaf@root()> jaas:group-add karaf mygroup

karaf@root()> jaas:group-delete karaf mygroup

karaf@root()> jaas:group-role-add mygroup myrole

karaf@root()> jaas:group-role-delete mygroup myrole

기본적으로 암호는 etc/users.properties 파일에 명확한 형식으로 저장됩니다.

etc/org.apache.karaf.jaas.cfg 구성 파일에서 암호화를 활성화할 수 있습니다.

################################################################################
#
#    Licensed to the Apache Software Foundation (ASF) under one or more
#    contributor license agreements.  See the NOTICE file distributed with
#    this work for additional information regarding copyright ownership.
#    The ASF licenses this file to You under the Apache License, Version 2.0
#    (the "License"); you may not use this file except in compliance with
#    the License.  You may obtain a copy of the License at
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
#    Unless required by applicable law or agreed to in writing, software
#    distributed under the License is distributed on an "AS IS" BASIS,
#    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#    See the License for the specific language governing permissions and
#    limitations under the License.
#
################################################################################

#
# Boolean enabling / disabling encrypted passwords
#
encryption.enabled = false

#
# Encryption Service name
#   the default one is 'basic'
#   a more powerful one named 'jasypt' is available
#       when installing the encryption feature
#
encryption.name =

#
# Encryption prefix
#
encryption.prefix = {CRYPT}

#
# Encryption suffix
#
encryption.suffix = {CRYPT}

#
# Set the encryption algorithm to use in Karaf JAAS login module
# Supported encryption algorithms follow:
#   MD2
#   MD5
#   SHA-1
#   SHA-256
#   SHA-384
#   SHA-512
#
encryption.algorithm = MD5

#
# Encoding of the encrypted password.
# Can be:
#   hexadecimal
#   base64
#
encryption.encoding = hexadecimal

encryption.enabled y가 true로 설정되면 암호 암호화가 활성화됩니다.

암호화가 활성화되면 사용자가 처음 로그인할 때 암호가 암호화됩니다. 암호화된 암호는 접두사가 지정되고 \{CRYPT\}로 접미사가 지정됩니다. 암호를 다시 암호화하려면 \{CRYPT\} 접두사 및 접미사 없이 암호를 clear( etc/users.properties 파일)으로 재설정할 수 있습니다. Apache Karaf는 이 암호가 붙지 않고 \{CRYPT\}로 접두사가 지정되어 있음을 감지하고 다시 암호화합니다.

etc/org.apache.karaf.jaas.cfg 구성 파일을 사용하면 고급 암호화 동작을 정의할 수 있습니다.

SSH 계층의 경우 Karaf는 키로 인증을 지원하므로 암호를 제공하지 않고 로그인할 수 있습니다.

SSH 클라이언트(Karaf 자체에서 제공하는 bin/client 또는 OpenSSH와 같은 ssh 클라이언트)는 Karaf SSHD(서버 측)에서 담당자를 식별하는 공개/개인 키 쌍을 사용합니다.

연결할 수 있는 키는 형식에 따라 etc/keys.properties 파일에 저장됩니다.

user=key,role

기본적으로 Karaf는 karaf 사용자에 대한 키를 허용합니다.

# karaf=AAAAB3NzaC1kc3MAAACBAP1/U4EddRIpUt9KnC7s5Of2EbdSPO9EAMMeP4C2USZpRV1AIlH7WT2NWPq/xfW6MPbLm1Vs14E7gB00b/JmYLdrmVClpJ+f6AR7ECLCT7up1/63xhv4O1fnxqimFQ8E+4P208UewwI1VBNaFpEy9nXzrith1yrv8iIDGZ3RSAHHAAAAFQCXYFCPFSMLzLKSuYKi64QL8Fgc9QAAAIEA9+GghdabPd7LvKtcNrhXuXmUr7v6OuqC+VdMCz0HgmdRWVeOutRZT+ZxBxCBgLRJFnEj6EwoFhO3zwkyjMim4TwWeotUfI0o4KOuHiuzpnWRbqN/C/ohNWLx+2J6ASQ7zKTxvqhRkImog9/hWuWfBpKLZl6Ae1UlZAFMO/7PSSoAAACBAKKSU2PFl/qOLxIwmBZPPIcJshVe7bVUpFvyl3BbJDow8rXfskl8wO63OzP/qLmcJM0+JbcRU/53JjTuyk31drV2qxhIOsLDC9dGCWj47Y7TyhPdXh/0dthTRBy6bqGtRPxGa7gJov1xm/UuYYXPIUR/3x9MAZvZ5xvE0kYXO+rx,admin

키 쌍을 생성하는 가장 쉬운 방법은 OpenSSH를 사용하는 것입니다.

다음을 사용하여 키 쌍을 만들 수 있습니다.

ssh-keygen -t dsa -f karaf.id_dsa -N karaf

이제 공개 및 개인 키가 있습니다.

-rw-------  1 jbonofre jbonofre    771 Jul 25 22:05 karaf.id_dsa
-rw-r--r--  1 jbonofre jbonofre    607 Jul 25 22:05 karaf.id_dsa.pub

etc/keys.properties 에 있는 karaf.id_dsa.pub 파일의 내용을 복사할 수 있습니다.

karaf=AAAAB3NzaC1kc3MAAACBAJLj9vnEhu3/Q9Cvym2jRDaNWkATgQiHZxmErCmiLRuD5Klfv+HT/+8WoYdnvj0YaXFP80phYhzZ7fbIO2LRFhYhPmGLa9nSeOsQlFuX5A9kY1120yB2kxSIZI0fU2hy1UCgmTxdTQPSYtdWBJyvO/vczoX/8I3FziEfss07Hj1NAAAAFQD1dKEzkt4e7rBPDokPOMZigBh4kwAAAIEAiLnpbGNbKm8SNLUEc/fJFswg4G4VjjngjbPZAjhkYe4+H2uYmynry6V+GOTS2kaFQGZRf9XhSpSwfdxKtx7vCCaoH9bZ6S5Pe0voWmeBhJXi/Sww8f2stpitW2Oq7V7lDdDG81+N/D7/rKDD5PjUyMsVqc1n9wCTmfqmi6XPEw8AAACAHAGwPn/Mv7P9Q9+JZRWtGq+i4pL1zs1OluiStCN9e/Ok96t3gRVKPheQ6IwLacNjC9KkSKrLtsVyepGA+V5j/N+Cmsl6csZilnLvMUTvL/cmHDEEhTIQnPNrDDv+tED2BFqkajQqYLgMWeGVqXsBU6IT66itZlYtrq4v6uDQG/o=,admin

karaf.id_dsa 개인 키를 사용하도록 클라이언트에 지정합니다.

bin/client -k ~/karaf.id_dsa

또는 ssh로

ssh -p 8101 -i ~/karaf.id_dsa karaf@localhost

Apache Karaf는 역할을 사용하여 RBAC(역할 기반 액세스 제어) 시스템이라는 리소스에 대한 액세스를 제어합니다.

역할은 다음을 제어하는 데 사용됩니다.

list = viewer
info = viewer
install = admin
uninstall = admin

#
# By default, only Karaf shell commands are secured, but additional services can be
# secured by expanding this filter
#
karaf.secured.services = (&(osgi.command.scope=*)(osgi.command.function=*))

karaf@root()> feature:install webconsole

Apache Karaf는 현재 사용자가 지정된 Cryostat 및/또는 작업을 호출할 수 있는지 확인하는 Cryostat를 제공합니다.

canInvoke() 작업은 현재 사용자의 역할을 가져오고, 역할 중 하나가 지정된 인수 값을 사용하여 및/또는 작업을 호출할 수 있는지 확인합니다.

일부 애플리케이션에서는 [BouncyCastle|http://www.bouncycastle.org]과 같은 특정 보안 공급자를 사용할 수 있어야 합니다.

JVM은 이러한 safety의 사용에 대해 몇 가지 제한 사항을 적용합니다. 서명하여 부팅 클래스 경로에서 사용할 수 있어야 합니다.

이러한 공급자를 배포하는 한 가지 방법은 $JAVA_HOME/jre/lib/ext 의 JRE 폴더에 배치하고 보안 정책 구성($JAVA_HOME/jre/lib/security/java.security)을 수정하여 이러한 공급자를 등록하는 것입니다.

이 접근 방식은 잘 작동하지만 글로벌 효과가 있으며 모든 서버를 적절하게 구성해야 합니다.

Apache Karaf는 추가 보안 공급자를 구성하는 간단한 방법을 제공합니다. * 공급자를 lib/ext *에 배치하고 etc/config.properties 구성 파일을 수정하여 다음 속성을 추가합니다.

org.apache.karaf.security.providers = xxx,yyy

이 속성의 값은 등록할 공급자 클래스 이름의 쉼표로 구분된 목록입니다.

예를 들어 bouncycastle 보안 공급자를 추가하려면 다음을 정의합니다.

org.apache.karaf.security.providers = org.bouncycastle.jce.provider.BouncyCastleProvider

또한 모든 번들이 해당 번들에 액세스할 수 있도록 시스템 번들에서 해당 공급자의 클래스에 대한 액세스를 제공할 수 있습니다.

동일한 구성 파일에서 org.osgi.framework.bootdelegation 속성을 수정하여 수행할 수 있습니다.

org.osgi.framework.bootdelegation = ...,org.bouncycastle*