Red Hat Fuse 7.8. Deploying into Apache Karaf. Deploying application packages into the Apache Karaf container. Last Updated:

(1)

Red Hat Fuse 7.8

Deploying into Apache Karaf

Deploying application packages into the Apache Karaf container

(2)

(3)

Red Hat Fuse 7.8 Deploying into Apache Karaf

Deploying application packages into the Apache Karaf container

(4)

Copyright © 2021 Red Hat, Inc.

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons

Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is

available at

http://creativecommons.org/licenses/by-sa/3.0/

. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must

provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,

Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift,

Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States

and other countries.

Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.

Java ® is a registered trademark of Oracle and/or its affiliates.

XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States

and/or other countries.

MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and

other countries.

Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the

official Joyent Node.js open source or commercial project.

The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marks

or trademarks/service marks of the OpenStack Foundation, in the United States and other

countries and are used with the OpenStack Foundation's permission. We are not affiliated with,

endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Abstract

(5)

. . . . . . . . . . . . . . . . . . . .

16.10.11.1. Requirements 16.10.12. Commands 16.10.12.1. feature:repo-list 16.10.12.2. feature:repo-add 16.10.12.3. feature:repo-refresh 16.10.12.4. feature:repo-remove 16.10.12.5. feature:list 89 90 90 90 91 92 93 93 93 93 94 94 95 96 96 96 97 97 97 100 100 100 100 102 102 102 103 105 105 105 105 106 107 107 108 108 108 108 108 109 109 109 109 110 110 110 111 111 113 113 114 Table of Contents

(10)

. . . . . . . . . . . . 16.10.12.6. feature:install 16.10.12.7. feature:start 16.10.12.8. feature:stop 16.10.12.9. feature:uninstall 16.10.13. Deployer 16.10.14. JMX FeatureMBean 16.10.14.1. Attributes 16.10.14.2. Operations 16.10.14.3. Notifications

CHAPTER 17. USING REMOTE CONNECTIONS TO MANAGE A CONTAINER 17.1. CONFIGURING A CONTAINER FOR REMOTE ACCESS

17.1.1. Overview

17.1.2. Configuring a standalone container for remote access 17.2. CONNECTING AND DISCONNECTING REMOTELY

17.2.1. Connecting to a Standalone Container from a Remote Container 17.2.1.1. Overview

17.2.1.2. Using the ssh:ssh console command 17.2.1.3. Disconnecting from a remote console

17.2.2. Connecting to a Container Using the Client Command-Line Utility 17.2.2.1. Using the remote client

17.2.2.2. Remote client default credentials

17.2.2.3. Disconnecting from a remote client console

17.2.3. Connecting to a Container Using the SSH Command-Line Utility 17.2.3.1. Overview

17.2.3.2. Prerequisites 17.2.3.3. Default key location

17.2.3.4. Creating a new SSH key pair

17.2.3.5. Installing the SSH public key in the container

17.2.3.6. Checking that public key authentication is supported 17.2.3.7. Adding the ssh Role to etc/keys.properties

17.2.3.8. Logging in using key-based SSH 17.3. STOPPING A REMOTE CONTAINER CHAPTER 18. BUILDING WITH MAVEN

18.1. MAVEN DIRECTORY STRUCTURE 18.1.1. Overview

18.1.2. Standard directory layout 18.1.3. pom.xml file

18.1.4. src and target directories 18.1.5. main and test directories 18.1.6. java directory

18.1.7. resources directory 18.1.8. Blueprint container

18.2. BOM FILE FOR APACHE KARAF CHAPTER 19. MAVEN INDEXER PLUGIN

19.1. LOG 19.1.1. Configuration files 19.1.2. Commands 19.1.2.1. log:clear 19.1.2.2. log:display 19.1.2.3. log:exception-display 115 116 116 116 117 117 117 118 118 119 119 119 119 119 119 119 119 120 120 120 121 122 122 122 122 122 123 123 124 124 125 125 126 126 126 126 127 127 127 127 127 127 127 130 130 131 134 134 134 136

(11)

. . . . 19.1.2.5. log:log 19.1.2.6. log:set 19.1.2.7. log:tail 19.1.3. JMX LogMBean 19.1.3.1. Attributes 19.1.3.2. Operations 19.1.4. Advanced configuration 19.1.4.1. Filters 19.1.4.2. Nested appenders 19.1.4.3. Error handlers

19.1.4.4. OSGi specific MDC attributes 19.1.4.5. Enhanced OSGi stack trace renderer 19.1.4.6. Custom appenders

CHAPTER 20. SECURITY 20.1. REALMS

20.1.1. Users, groups, roles, and passwords 20.1.1.1. Commands 20.1.1.1.1. jaas:realm-list 20.1.1.1.2. jaas:realm-manage 20.1.1.1.3. jaas:user-list 20.1.1.1.4. jaas:user-add 20.1.1.1.5. jaas:user-delete 20.1.1.1.6. jaas:group-add 20.1.1.1.7. jaas:group-delete 20.1.1.1.8. jaas:group-role-add 20.1.1.1.9. jaas:group-role-delete 20.1.1.1.10. jaas:update 20.1.1.1.11. jaas:cancel 20.1.2. Passwords encryption

20.1.3. Managing authentication by key 20.1.4. RBAC 20.1.4.1. OSGi services 20.1.4.2. Console 20.1.4.3. JMX 20.1.4.4. WebConsole 20.1.5. SecurityMBean 20.1.5.1. Operations 20.1.6. Security providers 137 137 138 139 139 139 139 139 139 140 140 141 142 143 143 144 145 145 145 145 146 146 146 146 147 147 147 147 147 149 150 150 150 151 152 152 153 153 Table of Contents

(12)

(13)

PART I. DEVELOPER GUIDE

This part contains information for developers.

(14)

CHAPTER 1. INTRODUCTION TO OSGI

Abstract

The OSGi specification supports modular application development by defining a runtime framework that simplifies building, deploying, and managing complex applications.

1.1. OVERVIEW

Apache Karaf is an OSGi-based runtime container for deploying and managing bundles. Apache Karaf also provides native operating system integration, and can be integrated into the operating system as a service so that the lifecycle is bound to the operating system.

Apache Karaf has the following structure:

Apache Karaf - a wrapper layer around the OSGi container implementation, which provides support for deploying the OSGi container as a runtime server. Runtime features provided by the Fuse include hot deployment, management, and administration features.

OSGi Framework - implements OSGi functionality, including managing dependencies and bundle lifecycles

1.2. ARCHITECTURE OF APACHE KARAF

Apache Karaf extends the OSGi layers with the following functionality:

Console - the console manages services, installs and manages applications and libraries, and interacts with the Fuse runtime. It provides console commands to administer instances of Fuse. See the Apache Karaf Console Reference.

Logging - the logging subsystem provides console commands to display, view and change log levels.

Deployment - supports both manual deployment of OSGi bundles using the bundle:install and

bundle:start commands and hot deployment of applications. See Section 6.1, “Hot Deployment”.

Provisioning - provides multiple mechanisms for installing applications and libraries. See

Chapter 9, Deploying Features.

Configuration - the properties files stored in the InstallDir/etc folder are continuously monitored, and changes to them are automatically propagated to the relevant services at configurable intervals.

Blueprint - is a dependency injection framework that simplifies interaction with the OSGi container. For example, providing standard XML elements to import and export OSGi services. When a Blueprint configuration file is copied to the hot deployment folder, Red Hat Fuse generates an OSGi bundle on-the-fly and instantiates the Blueprint context.

1.3. OSGI FRAMEWORK

(15)

The OSGi Alliance is an independent organization responsible for defining the features and capabilities of the OSGi Service Platform Release 4. The OSGi Service Platform is a set of open specifications that simplify building, deploying, and managing complex software applications.

OSGi technology is often referred to as the dynamic module system for Java. OSGi is a framework for Java that uses bundles to modularly deploy Java components and handle dependencies, versioning, classpath control, and class loading. OSGi’s lifecycle management allows you to load, start, and stop bundles without shutting down the JVM.

OSGi provides the best runtime platform for Java, a superior class loading architecture, and a registry for services. Bundles can export services, run processes, and have their dependencies managed. Each bundle can have its requirements managed by the OSGi container.

Fuse uses Apache Felix as its default OSGi implementation. The framework layers form the container where you install bundles. The framework manages the installation and updating of bundles in a dynamic, scalable manner, and manages the dependencies between bundles and services.

1.3.2. OSGi architecture

The OSGi framework contains the following:

Bundles — Logical modules that make up an application. See Section 1.5, “OSGi Bundles”. Service layer — Provides communication among modules and their contained components. This layer is tightly integrated with the lifecycle layer. See Section 1.4, “OSGi Services”.

Lifecycle layer — Provides access to the underlying OSGi framework. This layer handles the lifecycle of individual bundles so you can manage your application dynamically, including starting and stopping bundles.

Module layer — Provides an API to manage bundle packaging, dependency resolution, and class loading.

Execution environment — A configuration of a JVM. This environment uses profiles that define the environment in which bundles can work.

Security layer — Optional layer based on Java 2 security, with additional constraints and enhancements.

Each layer in the framework depends on the layer beneath it. For example, the lifecycle layer requires the module layer. The module layer can be used without the lifecycle and service layers.

1.4. OSGI SERVICES

1.4.1. Overview

An OSGi service is a Java class or service interface with service properties defined as name/value pairs. The service properties differentiate among service providers that provide services with the same service interface.

An OSGi service is defined semantically by its service interface, and it is implemented as a service object. A service’s functionality is defined by the interfaces it implements. Thus, different applications can implement the same service.

Service interfaces allow bundles to interact by binding interfaces, not implementations. A service

(16)

Service interfaces allow bundles to interact by binding interfaces, not implementations. A service interface should be specified with as few implementation details as possible.

1.4.2. OSGi service registry

In the OSGi framework, the service layer provides communication between Section 1.5, “OSGi Bundles”

and their contained components using the publish, find, and bind service model. The service layer contains a service registry where:

Service providers register services with the framework to be used by other bundles Service requesters find services and bind to service providers

Services are owned by, and run within, a bundle. The bundle registers an implementation of a service with the framework service registry under one or more Java interfaces. Thus, the service’s functionality is available to other bundles under the control of the framework, and other bundles can look up and use the service. Lookup is performed using the Java interface and service properties.

Each bundle can register multiple services in the service registry using the fully qualified name of its interface and its properties. Bundles use names and properties with LDAP syntax to query the service registry for services.

A bundle is responsible for runtime service dependency management activities including publication, discovery, and binding. Bundles can also adapt to changes resulting from the dynamic availability (arrival or departure) of the services that are bound to the bundle.

Event notification

Service interfaces are implemented by objects created by a bundle. Bundles can: Register services

Search for services

Receive notifications when their registration state changes

The OSGi framework provides an event notification mechanism so service requesters can receive notification events when changes in the service registry occur. These changes include the publication or retrieval of a particular service and when services are registered, modified, or unregistered.

Service invocation model

When a bundle wants to use a service, it looks up the service and invokes the Java object as a normal Java call. Therefore, invocations on services are synchronous and occur in the same thread. You can use callbacks for more asynchronous processing. Parameters are passed as Java object references. No marshalling or intermediary canonical formats are required as with XML. OSGi provides solutions for the problem of services being unavailable.

OSGi framework services

In addition to your own services, the OSGi framework provides the following optional services to manage the operation of the framework:

Package Admin service—allows a management agent to define the policy for managing Java package sharing by examining the status of the shared packages. It also allows the management

(17)

management agent to make decisions regarding any shared packages when an exporting bundle is uninstalled or updated.

The service also provides methods to refresh exported packages that were removed or updated since the last refresh, and to explicitly resolve specific bundles. This service can also trace dependencies between bundles at runtime, allowing you to see what bundles might be affected by upgrading.

Start Level service—enables a management agent to control the starting and stopping order of bundles. The service assigns each bundle a start level. The management agent can modify the start level of bundles and set the active start level of the framework, which starts and stops the appropriate bundles. Only bundles that have a start level less than, or equal to, this active start level can be active.

URL Handlers service—dynamically extends the Java runtime with URL schemes and content handlers enabling any component to provide additional URL handlers.

Permission Admin service—enables the OSGi framework management agent to administer the permissions of a specific bundle and to provide defaults for all bundles. A bundle can have a single set of permissions that are used to verify that it is authorized to execute privileged code. You can dynamically manipulate permissions by changing policies on the fly and by adding new policies for newly installed components. Policy files are used to control what bundles can do. Conditional Permission Admin service—extends the Permission Admin service with permissions that can apply when certain conditions are either true or false at the time the permission is checked. These conditions determine the selection of the bundles to which the permissions apply. Permissions are activated immediately after they are set.

The OSGi framework services are described in detail in separate chapters in the OSGi Service Platform Release 4 specification available from the release 4 download page on the OSGi Alliance web site.

OSGi Compendium services

In addition to the OSGi framework services, the OSGi Alliance defines a set of optional, standardized compendium services. The OSGi compendium services provide APIs for tasks such as logging and preferences. These services are described in the OSGi Service Platform, Service Compendium available from the release 4 download page on the OSGi Alliance Web site.

The Configuration Admin compendium service is like a central hub that persists configuration information and distributes it to interested parties. The Configuration Admin service specifies the configuration information for deployed bundles and ensures that the bundles receive that data when they are active. The configuration data for a bundle is a list of name-value pairs. See Section 1.2, “Architecture of Apache Karaf”.

1.5. OSGI BUNDLES

Overview

With OSGi, you modularize applications into bundles. Each bundle is a tightly coupled, dynamically loadable collection of classes, JARs, and configuration files that explicitly declare any external dependencies. In OSGi, a bundle is the primary deployment format. Bundles are applications that are packaged in JARs, and can be installed, started, stopped, updated, and removed.

OSGi provides a dynamic, concise, and consistent programming model for developing bundles.

Development and deployment are simplified by decoupling the service’s specification (Java interface) from its implementation.

(18)

The OSGi bundle abstraction allows modules to share Java classes. This is a static form of reuse. The shared classes must be available when the dependent bundle is started.

A bundle is a JAR file with metadata in its OSGi manifest file. A bundle contains class files and,

optionally, other resources and native libraries. You can explicitly declare which packages in the bundle are visible externally (exported packages) and which external packages a bundle requires (imported packages).

The module layer handles the packaging and sharing of Java packages between bundles and the hiding of packages from other bundles. The OSGi framework dynamically resolves dependencies among bundles. The framework performs bundle resolution to match imported and exported packages. It can also manage multiple versions of a deployed bundle.

Class Loading in OSGi

OSGi uses a graph model for class loading rather than a tree model (as used by the JVM). Bundles can share and re-use classes in a standardized way, with no runtime class-loading conflicts.

Each bundle has its own internal classpath so that it can serve as an independent unit if required. The benefits of class loading in OSGi include:

Sharing classes directly between bundles. There is no requirement to promote JARs to a parent class-loader.

(19)

CHAPTER 2. STARTING AND STOPPING APACHE KARAF

Abstract

Apache Karaf provides simple command-line tools for starting and stopping the server.

2.1. STARTING APACHE KARAF

The default way to deploy the Apache Karaf runtime is to deploy it as a standalone server with an active console. You can also deploy the runtime as a background process without a console.

2.1.1. Setting up your environment

You can start the Karaf runtime directly from the bin subdirectory of your installation, without modifying your environment. However, if you want to start it in a different folder you need to add the bin directory of your Karaf installation to the PATH environment variable, as follows:

Windows

set PATH=%PATH%;InstallDir\bin Linux/UNIX

export PATH=$PATH,InstallDir/bin`

2.1.2. Launching the runtime in console mode

If you are launching the Karaf runtime from the installation directory use the following command: Windows

bin\fuse.bat Linux/UNIX

./bin/fuse

If Karaf starts up correctly you should see the following on the console: 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)

(20)

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()>

NOTE

Since version Fuse 6.2.1, launching in console mode creates two processes: the parent process ./bin/karaf, which is executing the Karaf console; and the child process, which is executing the Karaf server in a java JVM. The shutdown behaviour remains the same as before, however. That is, you can shut down the server from the console using either Ctrl-D or osgi:shutdown, which kills both processes.

2.1.3. Launching the runtime in server mode

Launching in server mode runs Apache Karaf in the background, without a local console. You would then connect to the running instance using a remote console. See Section 17.2, “Connecting and

Disconnecting Remotely” for details.

To launch Karaf in server mode, run the following Windows

bin\start.bat Linux/UNIX

./bin/start

2.1.4. Launching the runtime in client mode

In production environments you might want to have a runtime instance accessible using only a local console. In other words, you cannot connect to the runtime remotely through the SSH console port. You can do this by launching the runtime in client mode, using the following command:

Windows

bin\fuse.bat client Linux/UNIX

(21)

NOTE

Launching in client mode suppresses only the SSH console port (usually port 8101). Other Karaf server ports (for example, the JMX management RMI ports) are opened as normal.

2.1.5. Running Fuse in debug mode

Running Fuse in debug mode helps identify and resolve errors more efficiently. This option is disabled by default. When enabled, Fuse starts a JDWP socket on port 5005.

You have three approaches to run Fuse in debug mode.

Section 2.1.5.1, “Use the Karaf environment variable” Section 2.1.5.2, “Run Fuse debug”

Section 2.1.5.3, “Run Fuse debugs”

2.1.5.1. Use the Karaf environment variable

This approach enables the KARAF_DEBUG environment variable (=1), and then you start the container. $ export KARAF_DEBUG=1

$ bin/start

2.1.5.2. Run Fuse debug

This approach runs debug where the suspend option is set to n (no). $ bin/fuse debug

2.1.5.3. Run Fuse debugs

This approach runs debugs where the suspend option is set to y (yes).

NOTE

Setting suspend to yes causes the JVM to pause just before running main() until a debugger is attached and then it resumes execution.

$ bin/fuse debugs

2.2. STOPPING APACHE KARAF

You can stop an instance of Apache Karaf either from within a console, or using a stop script.

2.2.1. Stopping an instance from a local console

If you launched the Karaf instance by running fuse or fuse client, you can stop it by doing one of the following at the karaf> prompt:

Type shutdown

(22)

Press Ctrl+D

2.2.2. Stopping an instance running in server mode

You can stop a locally running Karaf instance (root container), by invoking the stop(.bat) from the

InstallDir/bin directory, as follows:

Windows bin\stop.bat Linux/UNIX

./bin/stop

The shutdown mechanism invoked by the Karaf stop script is similar to the shutdown mechanism implemented in Apache Tomcat. The Karaf server opens a dedicated shutdown port (not the same as the SSH port) to receive the shutdown notification. By default, the shutdown port is chosen randomly, but you can configure it to use a specific port if you prefer.

You can optionally customize the shutdown port by setting the following properties in the

InstallDir/etc/config.properties file: karaf.shutdown.port

Specifies the TCP port to use as the shutdown port. Setting this property to -1 disables the port. Default is 0 (for a random port).

NOTE

If you wanted to use the bin/stop script to shut down the Karaf server running on a remote host, you would need to set this property equal to the remote host’s shutdown port. But beware that this setting also affects the Karaf server located on the same host as the etc/config.properties file.

karaf.shutdown.host

Specifies the hostname to which the shutdown port is bound. This setting could be useful on a multi-homed host. Defaults to localhost.

NOTE

If you wanted to use the bin/stop script to shut down the Karaf server running on a remote host, you would need to set this property to the hostname (or IP address) of the remote host. But beware that this setting also affects the Karaf server located on the same host as the etc/config.properties file.

karaf.shutdown.port.file

After the Karaf instance starts up, it writes the current shutdown port to the file specified by this property. The stop script reads the file specified by this property to discover the value of the current shutdown port. Defaults to ${karaf.data}/port.

karaf.shutdown.command

(23)

provides an elementary level of security, as long as the UUID value is kept a secret. For example, the

etc/config.properties file could be read-protected to prevent this value from being read by ordinary

users.

When Apache Karaf is started for the very first time, a random UUID value is automatically generated and this setting is written to the end of the etc/config.properties file. Alternatively, if

karaf.shutdown.command is already set, the Karaf server uses the pre-existing UUID value (which

enables you to customize the UUID setting, if required).

NOTE

If you wanted to use the bin/stop script to shut down the Karaf server running on a remote host, you would need to set this property to be equal to the value of the remote host’s karaf.shutdown.command. But beware that this setting also affects the Karaf server located on the same host as the etc/config.properties file.

2.2.3. Stopping a remote instance

You can stop a container instance running on a remote host as described in Section 17.3, “Stopping a Remote Container”.

(24)

CHAPTER 3. BASIC SECURITY

This chapter describes the basic steps to configure security before you start Karaf for the first time. By default, Karaf is secure, but none of its services are remotely accessible. This chapter explains how to enable secure access to the ports exposed by Karaf.

3.1. CONFIGURING BASIC SECURITY

3.1.1. Overview

The Apache Karaf runtime is secured against network attack by default, because all of its exposed ports require user authentication and no users are defined initially. In other words, the Apache Karaf runtime is remotely inaccessible by default.

If you want to access the runtime remotely, you must first customize the security configuration, as described here.

3.1.2. Before you start the container

If you want to enable remote access to the Karaf container, you must create a secure JAAS user before starting the container:

3.1.3. Create a secure JAAS user

By default, no JAAS users are defined for the container, which effectively disables remote access (it is impossible to log on).

To create a secure JAAS user, edit the InstallDir/etc/users.properties file and add a new user field, as follows:

Username=Password,admin

Where Username and Password are the new user credentials. The admin role gives this user the privileges to access all administration and management functions of the container.

Do not define a numeric username with a leading zero. Such usernames will always cause a login attempt to fail. This is because the Karaf shell, which the console uses, drops leading zeros when the input

appears to be a number. For example: karaf@root> echo 0123

123

karaf@root> echo 00.123 0.123

(25)

WARNING

It is strongly recommended that you define custom user credentials with a strong password.

3.1.4. Role-based access control

The Karaf container supports role-based access control, which regulates access through the JMX protocol, the Karaf command console, and the Fuse Management console. When assigning roles to users, you can choose from the set of standard roles, which provide the levels of access described in

Table 3.1, “Standard Roles for Access Control”. Table 3.1. Standard Roles for Access Control

Roles Description

viewer Grants read-only access to the container.

manager Grants read-write access at the appropriate level for

ordinary users, who want to deploy and run

applications. But blocks access to sensitive container configuration settings.

admin Grants unrestricted access to the container.

ssh Grants permission for remote console access

through the SSH port.

For more details about role-based access control, see Role-Based Access Control.

3.1.5. Ports exposed by the Apache Karaf container

The following ports are exposed by the container:

Console port — enables remote control of a container instance, through Apache Karaf shell commands. This port is enabled by default and is secured both by JAAS authentication and by SSH.

JMX port — enables management of the container through the JMX protocol. This port is enabled by default and is secured by JAAS authentication.

Web console port — provides access to an embedded Undertow container that can host Web console servlets. By default, the Fuse Console is installed in the Undertow container.

3.1.6. Enabling the remote console port

You can access the remote console port whenever both of the following conditions are true:



(26)

JAAS is configured with at least one set of login credentials.

The Karaf runtime has not been started in client mode (client mode disables the remote console port completely).

For example, to log on to the remote console port from the same machine where the container is running, enter the following command:

./client -u Username -p Password

Where the Username and Password are the credentials of a JAAS user with the ssh role. When accessing the Karaf console through the remote port, your privileges depend on the roles assigned to the user in the etc/users.properties file. If you want access to the complete set of console commands, the user account must have the admin role.

3.1.7. Strengthening security on the remote console port

You can employ the following measures to strengthen security on the remote console port: Make sure that the JAAS user credentials have strong passwords.

Customize the X.509 certificate (replace the Java keystore file, InstallDir/etc/host.key, with a custom key pair).

3.1.8. Enabling the JMX port

The JMX port is enabled by default and secured by JAAS authentication. In order to access the JMX port, you must have configured JAAS with at least one set of login credentials. To connect to the JMX port, open a JMX client (for example, jconsole) and connect to the following JMX URI:

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

You must also provide valid JAAS credentials to the JMX client in order to connect.

NOTE

In general, the tail of the JMX URI has the format /karaf-ContainerName. If you change the container name from root to some other name, you must modify the JMX URI accordingly.

3.1.9. Strengthening security on the Fuse Console port

The Fuse Console is already secured by JAAS authentication. To add SSL security, see Securing the Undertow HTTP Server.

(27)

CHAPTER 4. INSTALLING APACHE KARAF AS A SERVICE

This chapter provides information on how you can start an Apache Karaf instance as a system service using the provided templates.

4.1. OVERVIEW

Using the service script templates, you can run a Karaf instance with the help of operating system specific init scripts. You can find these templates under the bin/contrib directory.

4.2. RUNNING KARAF AS A SERVICE

The karaf-service.sh utility helps you to customize the templates. This utility automatically identifies the operating system and the default init system and generates ready-to-use init scripts. You can also customize the scripts to adapt them to the environment, by setting JAVA_HOME and a few other environment variables.

The generated scripts are composed of two files: The init script

The init configuration file

4.3. SYSTEMD

When the karaf-service.sh utility identifies systemd, it generates three files: A systemd unit file to manage the root Apache Karaf container.

A systemd environment file with variables used by the root Apache Karaf container.

(Not supported) A systemd template unit file to manage Apache Karaf child containers.

For example, to set up a service for a Karaf instance installed at /opt/karaf-4, giving the service the name, karaf-4:

$ ./karaf-service.sh -k /opt/karaf-4 -n karaf-4

Writing service file "/opt/karaf-4/bin/contrib/karaf-4.service" Writing service configuration file ""/opt/karaf-4/etc/karaf-4.conf" Writing service file "/opt/karaf-4/bin/contrib/[email protected]"

$ sudo cp /opt/karaf-4/bin/contrib/karaf-4.service /etc/systemd/system $ sudo systemctl enable karaf-4.service

4.4. SYSV

When the karaf-service.sh utility identifies a SysV system, it generates two files: An init script to manage the root Apache Karaf container.

An environment file with variables used by the root Apache Karaf container.

For example, to set up a service for a Karaf instance installed at /opt/karaf-4, giving the service the name, karaf-4:

(28)

$ ./karaf-service.sh -k /opt/karaf-4 -n karaf-4 Writing service file "/opt/karaf-4/bin/contrib/karaf-4"

Writing service configuration file "/opt/karaf-4/etc/karaf-4.conf" $ sudo ln -s /opt/karaf-4/bin/contrib/karaf-4 /etc/init.d/

$ sudo chkconfig karaf-4 on

NOTE

To enable the service startup upon boot, refer to your operating system init guide.

4.5. SOLARIS SMF

When the karaf-service.sh utility identifies a Solaris operating system, it generates a single file. For example, to set up a service for a Karaf instance installed at /opt/karaf-4, giving the service the name, karaf-4:

$ ./karaf-service.sh -k /opt/karaf-4 -n karaf-4

Writing service file "/opt/karaf-4/bin/contrib/karaf-4.xml" $ sudo svccfg validate /opt/karaf-4/bin/contrib/karaf-4.xml $ sudo svccfg import /opt/karaf-4/bin/contrib/karaf-4.xml

NOTE

The generated SMF descriptor is defined as transient, so that you can execute the start method only once.

4.6. WINDOWS

Installation of Apache Karaf as Windows service is supported through winsw. To install Apache Karaf as Windows service, perform the following steps:

1. Rename the karaf-service-win.exe file to karaf-4.exe. 2. Rename the karaf-service-win.xml file to karaf-4.xml. 3. Customize the service descriptor as required.

4. Use the service executable to install, start and stop the service. For example:

C:\opt\apache-karaf-4\bin\contrib> karaf-4.exe install C:\opt\apache-karaf-4\bin\contrib> karaf-4.exe start

4.7. KARAF-SERVICE.SH OPTIONS

You can specify options to the karaf-service.sh utility either as command-line options or by setting environment variables, as follows:

(29)

Command Line Option Environment Variable Description

-k KARAF_SERVICE_PATH Karaf installation path

-d KARAF_SERVICE_DATA Karaf data path (defaults to

${KARAF_SERVICE_PATH}/d ata)

-c KARAF_SERVICE_CONF Karaf configuration file (defaults

to

${KARAF_SERVICE_PATH}/e tc/${KARAF_SERVICE_NAM E}.conf)

-t KARAF_SERVICE_ETC Karaf etc path (defaults to

${KARAF_SERVICE_PATH}/e tc})

-p KARAF_SERVICE_PIDFILE Karaf PID path (defaults to

${KARAF_SERVICE_DATA}/$ {KARAF_SERVICE_NAME}.pi d)

-n KARAF_SERVICE_NAME Karaf service name (defaults to

karaf)

-e KARAF_ENV Specifies an environment variable

setting, NAME=VALUE, for the service (can be specified more than once)

-u KARAF_SERVICE_USER Karaf user

-g KARAF_SERVICE_GROUP Karaf group (defaults to

${KARAF_SERVICE_USER})

-l KARAF_SERVICE_LOG Karaf console log (defaults to

${KARAF_SERVICE_DATA}/l og/${KARAF_SERVICE_NAM E}-console.log)

-f KARAF_SERVICE_TEMPLAT

E Template file to use

-x KARAF_SERVICE_EXECUTA

BLE Karaf executable name (defaultsto karaf — must support the daemon and stop commands)

-h Help message

(30)

CHAPTER 5. BUILDING AN OSGI BUNDLE

Abstract

This chapter describes how to build an OSGi bundle using Maven. For building bundles, the Maven bundle plug-in plays a key role, because it enables you to automate the generation of OSGi bundle headers (which would otherwise be a tedious task). Maven archetypes, which generate a complete sample project, can also provide a starting point for your bundle projects.

5.1. GENERATING A BUNDLE PROJECT

5.1.1. Generating bundle projects with Maven archetypes

To help you get started quickly, you can invoke a Maven archetype to generate the initial outline of a Maven project (a Maven archetype is analogous to a project wizard). The following Maven archetype generates a project for building OSGi bundles.

5.1.2. Apache Camel archetype

The Apache Camel OSGi archetype creates a project for building a route that can be deployed into the OSGi container.

Following example shows how to generate a camel-blueprint project using the Maven archetype command with the coordinates, GroupId:ArtifactId:Version, .

mvn archetype:generate \

-DarchetypeGroupId=org.apache.camel.archetypes \ -DarchetypeArtifactId=camel-archetype-blueprint \ -DarchetypeVersion=2.23.2.fuse-780036-redhat-00001

After running this command, Maven prompts you to specify the GroupId, ArtifactId, and Version.

5.1.3. Building the bundle

By default, the preceding archetypes create a project in a new directory, whose name is the same as the specified artifact ID, ArtifactId. To build the bundle defined by the new project, open a command

prompt, go to the project directory (that is, the directory containing the pom.xml file), and enter the following Maven command:

mvn install

The effect of this command is to compile all of the Java source files, to generate a bundle JAR under the ArtifactId/target directory, and then to install the generated JAR in the local Maven repository.

5.2. MODIFYING AN EXISTING MAVEN PROJECT

5.2.1. Overview

If you already have a Maven project and you want to modify it so that it generates an OSGi bundle, perform the following steps:

(31)

2. Section 5.2.3, “Add the bundle plug-in to your POM”. 3. Section 5.2.4, “Customize the bundle plug-in”.

4. Section 5.2.5, “Customize the JDK compiler version”.

5.2.2. Change the package type to bundle

Configure Maven to generate an OSGi bundle by changing the package type to bundle in your project’s

pom.xml file. Change the contents of the packaging element to bundle, as shown in the following

example: <project ... > ... <packaging>bundle</packaging> ... </project>

The effect of this setting is to select the Maven bundle plug-in, maven-bundle-plugin, to perform packaging for this project. This setting on its own, however, has no effect until you explicitly add the bundle plug-in to your POM.

5.2.3. Add the bundle plug-in to your POM

To add the Maven bundle plug-in, copy and paste the following sample plugin element into the

project/build/plugins section of your project’s pom.xml file:

<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>

Where the bundle plug-in is configured by the settings in the instructions element.

5.2.4. Customize the bundle plug-in

(32)

For some specific recommendations on configuring the bundle plug-in for Apache CXF, see Section 5.3, “Packaging a Web Service in a Bundle”.

5.2.5. Customize the JDK compiler version

It is almost always necessary to specify the JDK version in your POM file. If your code uses any modern features of the Java language—such as generics, static imports, and so on—and you have not

customized the JDK version in the POM, Maven will fail to compile your source code. It is not sufficient to set the JAVA_HOME and the PATH environment variables to the correct values for your JDK, you must also modify the POM file.

To configure your POM file, so that it accepts the Java language features introduced in JDK 1.8, add the following maven-compiler-plugin plug-in settings to your POM (if they are not already present):

<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>

5.3. PACKAGING A WEB SERVICE IN A BUNDLE

5.3.1. Overview

This section explains how to modify an existing Maven project for a Apache CXF application, so that the project generates an OSGi bundle suitable for deployment in the Red Hat Fuse OSGi container. To convert the Maven project, you need to modify the project’s POM file and the project’s Blueprint file(s) (located in META-INF/spring).

5.3.2. Modifying the POM file to generate a bundle

To configure a Maven POM file to generate a bundle, there are essentially two changes you need to make: change the POM’s package type to bundle; and add the Maven bundle plug-in to your POM. For details, see Section 5.1, “Generating a Bundle Project”.

5.3.3. Mandatory import packages

In order for your application to use the Apache CXF components, you need to import their packages into the application’s bundle. Because of the complex nature of the dependencies in Apache CXF, you cannot rely on the Maven bundle plug-in, or the bnd tool, to automatically determine the needed

(33)

imports. You will need to explicitly declare them.

You need to import the following packages into your bundle: 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.3.4. Sample Maven bundle plug-in instructions

Example 5.1, “Configuration of Mandatory Import Packages” shows how to configure the Maven bundle plug-in in your POM to import the mandatory packages. The mandatory import packages appear as a comma-separated list inside the Import-Package element. Note the appearance of the wildcard, *, as the last element of the list. The wildcard ensures that the Java source files from the current bundle are scanned to discover what additional packages need to be imported.

Example 5.1. Configuration of Mandatory Import Packages <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>

(34)

... </instructions> </configuration> </plugin> </plugins> </build> ... </project>

5.3.5. Add a code generation plug-in

A Web services project typically requires code to be generated. Apache CXF provides two Maven plug-ins for the JAX-WS front-end, which enable tyou to integrate the code generation step into your build. The choice of plug-in depends on whether you develop your service using the Java-first approach or the WSDL-first approach, as follows:

Java-first approach—use the cxf-java2ws-plugin plug-in. WSDL-first approach—use the cxf-codegen-plugin plug-in.

5.3.6. OSGi configuration properties

The OSGi Configuration Admin service defines a mechanism for passing configuration settings to an OSGi bundle. You do not have to use this service for configuration, but it is typically the most convenient way of configuring bundle applications. Blueprint provides support for OSGi configuration, enabling you to substitute variables in a Blueprint file using values obtained from the OSGi Configuration Admin service.

For details of how to use OSGi configuration properties, see Section 5.3.7, “Configuring the Bundle Plug-In” and Section 9.6, “Add OSGi configurations to the feature”.

5.3.7. Configuring the Bundle Plug-In

Overview

A bundle plug-in requires very little information to function. All of the required properties use default settings to generate a valid OSGi bundle.

While you can create a valid bundle using just the default values, you will probably want to modify some of the values. You can specify most of the properties inside the plug-in’s instructions element.

Configuration properties

Some of the commonly used configuration properties are:

Bundle-SymbolicName Bundle-Name

Bundle-Version Export-Package

(35)

Private-Package Import-Package

Setting a bundle’s symbolic name

By default, the bundle plug-in sets the value for the Bundle-SymbolicName property to groupId + "." +

artifactId, with the following exceptions:

If groupId has only one section (no dots), the first package name with classes is returned. For example, if the group Id is commons-logging:commons-logging, the bundle’s symbolic name is org.apache.commons.logging.

If artifactId is equal to the last section of groupId, then groupId is used.

For example, if the POM specifies the group ID and artifact ID as org.apache.maven:maven, the bundle’s symbolic name is org.apache.maven.

If artifactId starts with the last section of groupId, that portion is removed.

For example, if the POM specifies the group ID and artifact ID as

org.apache.maven:maven-core, the bundle’s symbolic name is org.apache.maven.core.

To specify your own value for the bundle’s symbolic name, add a Bundle-SymbolicName child in the plug-in’s instructions element, as shown in Example 5.2, “Setting a bundle’s symbolic name”.

Example 5.2. Setting a bundle’s symbolic name <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <configuration> <instructions> <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName> ... </instructions> </configuration> </plugin>

Setting a bundle’s name

By default, a bundle’s name is set to ${project.name}.

To specify your own value for the bundle’s name, add a Bundle-Name child to the plug-in’s instructions element, as shown in Example 5.3, “Setting a bundle’s name”.

Example 5.3. Setting a bundle’s name <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <configuration> <instructions> <Bundle-Name>JoeFred</Bundle-Name> ...

(36)

</instructions> </configuration> </plugin>

Setting a bundle’s version

By default, a bundle’s version is set to ${project.version}. Any dashes (-) are replaced with dots ( .) and the number is padded up to four digits. For example, 4.2-SNAPSHOT becomes 4.2.0.SNAPSHOT. To specify your own value for the bundle’s version, add a Bundle-Version child to the plug-in’s

instructions element, as shown in Example 5.4, “Setting a bundle’s version”. Example 5.4. Setting a bundle’s version

<plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <configuration> <instructions> <Bundle-Version>1.0.3.1</Bundle-Version> ... </instructions> </configuration> </plugin>

Specifying exported packages

By default, the OSGi manifest’s Export-Package list is populated by all of the packages in your local Java source code (under src/main/java), except for the default package, ., and any packages containing .impl or .internal.

IMPORTANT

If you use a Private-Package element in your plug-in configuration and you do not specify a list of packages to export, the default behavior includes only the packages listed in the Private-Package element in the bundle. No packages are exported.

The default behavior can result in very large packages and in exporting packages that should be kept private. To change the list of exported packages you can add an Export-Package child to the plug-in’s

instructions element.

The Export-Package element specifies a list of packages that are to be included in the bundle and that are to be exported. The package names can be specified using the * wildcard symbol. For example, the entry com.fuse.demo.* includes all packages on the project’s classpath that start with com.fuse.demo. You can specify packages to be excluded be prefixing the entry with !. For example, the entry

!com.fuse.demo.private excludes the package com.fuse.demo.private.

When excluding packages, the order of entries in the list is important. The list is processed in order from the beginning and any subsequent contradicting entries are ignored.

(37)

For example, to include all packages starting with com.fuse.demo except the package

com.fuse.demo.private, list the packages using:

!com.fuse.demo.private,com.fuse.demo.*

However, if you list the packages using com.fuse.demo.*,!com.fuse.demo.private, then

com.fuse.demo.private is included in the bundle because it matches the first pattern.

Specifying private packages

If you want to specify a list of packages to include in a bundle without exporting them, you can add a

Private-Package instruction to the bundle plug-in configuration. By default, if you do not specify a Private-Package instruction, all packages in your local Java source are included in the bundle.

IMPORTANT

If a package matches an entry in both the Private-Package element and the

Export-Package element, the Export-Export-Package element takes precedence. The package is

added to the bundle and exported.

The Private-Package element works similarly to the Export-Package element in that you specify a list of packages to be included in the bundle. The bundle plug-in uses the list to find all classes on the

project’s classpath that are to be included in the bundle. These packages are packaged in the bundle, but not exported (unless they are also selected by the Export-Package instruction).

Example 5.5, “Including a private package in a bundle” shows the configuration for including a private package in a bundle

Example 5.5. Including a private package in a bundle <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <configuration> <instructions> <Private-Package>org.apache.cxf.wsdlFirst.impl</Private-Package> ... </instructions> </configuration> </plugin>

Specifying imported packages

By default, the bundle plug-in populates the OSGi manifest’s Import-Package property with a list of all the packages referred to by the contents of the bundle.

While the default behavior is typically sufficient for most projects, you might find instances where you want to import packages that are not automatically added to the list. The default behavior can also result in unwanted packages being imported.

To specify a list of packages to be imported by the bundle, add an Import-Package child to the plug-in’s

instructions element. The syntax for the package list is the same as for the Export-Package element

and the Private-Package element.

IMPORTANT

(38)

IMPORTANT

When you use the Import-Package element, the plug-in does not automatically scan the bundle’s contents to determine if there are any required imports. To ensure that the contents of the bundle are scanned, you must place an * as the last entry in the package list.

Example 5.6, “Specifying the packages imported by a bundle” shows the configuration for specifying the packages imported by a bundle

Example 5.6. Specifying the packages imported by a bundle <plugin>

<groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <configuration>

<Import-Package>javax.jws, javax.wsdl, org.apache.cxf.bus, org.apache.cxf.bus.spring, org.apache.cxf.bus.resource, org.apache.cxf.configuration.spring, org.apache.cxf.resource, org.springframework.beans.factory.config, * </Import-Package> ... </instructions> </configuration> </plugin>

More information

For more information on configuring a bundle plug-in, see:

olink:OsgiDependencies/OsgiDependencies Apache Felix documentation

Peter Kriens' aQute Software Consultancy web site

5.3.8. OSGI configAdmin file naming convention

PID strings (symbolic-name syntax) allow hyphens in the OSGI specification. However, hyphens are interpreted by Apache Felix.fileinstall and config:edit shell commands to differentiate a "managed service" and "managed service factory". Therefore, it is recommended to not use hyphens elsewhere in a PID string.

NOTE

(39)

CHAPTER 6. HOT DEPLOYMENT VS MANUAL DEPLOYMENT

Abstract

Fuse provides two different approaches for deploying files: hot deployment or manual deployment. If you need to deploy a collection of related bundles it is recommended that you deploy them together as a feature, rather than singly (see Chapter 9, Deploying Features).

6.1. HOT DEPLOYMENT

6.1.1. Hot deploy directory

Fuse monitors files in the FUSE_HOME/deploy directory and hot deploys everything in this directory. Each time a file is copied to this directory, it is installed in the runtime and started. You can subsequently update or delete the files in the FUSE_HOME/deploy directory, and the changes are handled

automatically.

For example, if you have just built the bundle, ProjectDir/target/foo-1.0-SNAPSHOT.jar, you can deploy this bundle by copying it to the FUSE_HOME/deploy directory as follows (assuming you are working on a UNIX platform):

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

6.2. HOT UNDEPLOYING A BUNDLE

To undeploy a bundle from the hot deploy directory, simply delete the bundle file from the

FUSE_HOME/deploy directory while the Apache Karaf container is running.

IMPORTANT

The hot undeploy mechanism does not work while the container is shut down. If you shut down the Karaf container, delete the bundle file from FUSE_HOME/deploy directory, and then restart the Karaf container, the bundle will not be undeployed after you restart the container.

You can also undeploy a bundle by using the bundle:uninstall console command.

6.3. MANUAL DEPLOYMENT

6.3.1. Overview

You can manually deploy and undeploy bundles by issuing commands at the Fuse console.

6.3.2. Installing a bundle

Use the bundle:install command to install one or more bundles in the OSGi container. This command has the following syntax:

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

Where UrlList is a whitespace-separated list of URLs that specify the location of each bundle to deploy.

(40)

Where UrlList is a whitespace-separated list of URLs that specify the location of each bundle to deploy. The following command arguments are supported:

-s

Start the bundle after installing.

--start

Same as -s.

--help

Show and explain the command syntax.

For example, to install and start the bundle, ProjectDir/target/foo-1.0-SNAPSHOT.jar, enter the following command at the Karaf console prompt:

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

NOTE

On Windows platforms, you must be careful to use the correct syntax for the file URL in this command. See Section 15.1, “File URL Handler” for details.

6.3.3. Uninstalling a bundle

To uninstall a bundle, you must first obtain its bundle ID using the bundle:list command. You can then uninstall the bundle using the bundle:uninstall command (which takes the bundle ID as its argument). For example, if you have already installed the bundle named A Camel OSGi Service Unit, entering

bundle:list at the console prompt might produce output like the following:

...

[ 181] [Resolved ] [ ] [ ] [ 60] A Camel OSGi Service Unit (1.0.0.SNAPSHOT) You can now uninstall the bundle with the ID, 181, by entering the following console command:

bundle:uninstall 181

6.3.4. URL schemes for locating bundles

When specifying the location URL to the bundle:install command, you can use any of the URL schemes supported by Fuse, which includes the following scheme types:

Section 15.1, “File URL Handler”.

Section 15.2, “HTTP URL Handler”.

Section 15.3, “Mvn URL Handler”.

6.4. REDEPLOYING BUNDLES AUTOMATICALLY USING

BUNDLE:WATCH

In a development environment—where a developer is constantly changing and rebuilding a bundle—it is typically necessary to re-install the bundle multiple times. Using the bundle:watch command, you can

(41)

instruct Karaf to monitor your local Maven repository and re-install a particular bundle automatically, as soon as it changes in your local Maven repository.

For example, given a particular bundle—with bundle ID, 751—you can enable automatic redeployment by entering the command:

bundle:watch 751

Now, whenever you rebuild and install the Maven artifact into your local Maven repository (for example, by executing mvn install in your Maven project), the Karaf container automatically re-installs the changed Maven artifact. For more details, see Apache Karaf Console Reference.

IMPORTANT

Using the bundle:watch command is intended for a development environment only. It is not recommended for use in a production environment.