Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Configuring and Running Red Hat JBoss Fuse

Red Hat JBoss Fuse

Managing the runtime container

Red Hat

Version 6.0

Copyright © 2013 Red Hat, Inc. and/or its affiliates.

13 Oct 2017
Revision History
08/16/2012
Moved security, JMX, thread pools, and hot deploy information from the config chapter to independent chapters
8/30/12
added chapter on incremental patching
09/10/12
added chapter on managing child containers
9/13/2012
added chapter on configuring the Fabric Maven proxy
10/04/2012
added chapters on joining and creating a fabric
02/19/2013
added on deploying a new message broker

Abstract

This guide provides information and instructions for starting/stopping Red Hat JBoss Fuse, using remote and child instances of the runtime, configuring Red Hat JBoss Fuse, configuring logging for the entire runtime or per component application, configuring where persistent data (messages, log files, OSGi bundles, transaction logs) is stored, and configuring failover deployments.

Abstract

If you are using a standalone container, you can change the features it automatically loads the first time it is started.

Overview
Copy link

The first time you start a standalone container, the container looks in the etc/org.apache.karaf.features.cfg file to discover the feature URLs (feature repository locations) and to determine which features it will load. By default, Red Hat JBoss Fuse loads a large number of features and you may not need all of them. You may also decide you need features that are not included in the default configuration.
Warning
The features loaded by a Fabric Container are controlled by the container's profiles. Changing the values as described below will have no effect on a Fabric container.
The values in etc/org.apache.karaf.features.cfg are only used the first time the container is started. On subsequent start-ups, the container uses the contents of the InstallDir/data directory to determine what to load. If you need to adjust the features loaded into a container, you can delete the data directory, but this will also destroy any state or persistence information stored by the container.
For more on features and how they are used in Red Hat JBoss Fuse, see chapter "Deploying Features" in "Deploying into the Container".

Modifying the default installed features
Copy link

By default, JBoss Fuse installs a large number of features, including some that you may not want to deploy.
You can change the initial set of installed features by editing the featuresBoot property.

Modifying the default set of feature URLs
Copy link

JBoss Fuse registers a number of URLs that point to feature repositories on start-up. You can change the initial set of feature URLs by editing the featureRepositories property.
Revision History
06/01/12
Red Hat JBoss Fuse can generate a service wrapper that can be easily configured to install Red Hat JBoss Fuse as a system service.

Abstract

The Red Hat JBoss Fuse installer generates a service wrapper that can be easily configured to install JBoss Fuse as a system service.
Installing Red Hat JBoss Fuse as a system service is a three two step process:
  1. Generate the service wrapper for your system.
    See Section 2.1, “Generating the Service Wrapper”.
  2. Configure the launch script for your system.
    See Section 2.2, “Configure the Script”
  3. Configure the service wrapper for your system.
    See Section 2.3, “Configuring the Wrapper”.
  4. Install the service wrapper as system service.
    See Section 2.4, “Installing and Starting the Service”.

2.1. Generating the Service Wrapper
Copy link

Abstract

The service wrapper is generated using an optional feature of the command console. Once installed the feature will generate the appropriate start-up scripts, configuration, an libraries to install a broker as a system service.

Overview
Copy link

The Red Hat JBoss Fuse console's wrapper feature generates a wrapper around the JBoss Fuse runtime that allows you to install a message broker as a system service. The wrapper feature does not come preinstalled in the console, so before you can generate the service wrapper you must install the wrapper feature.
Once the feature is installed the console gains a wrapper:install command. Running this command generates a generic service wrapper in the JBoss Fuse installation.

Procedure
Copy link

To generate the service wrapper:
  1. Start JBoss Fuse in console mode using the fuse command.
  2. Once the console is started and the command prompt appears, enter features:install wrapper.
    The features:install command will locate the required libraries to provision the wrapper feature and deploy it into the run time.
  3. Generate the wrapper by entering wrapper:install -n serviceName -d displayName -D description.
    The wrapper:install command has the options described in Table 2.1, “Wrapper Install Options”.
    Expand
    Table 2.1. Wrapper Install Options
    OptionDefaultDescription
    -sAUTO_START(Windows only) Specifies the mode in which the service is installed. Valid values are AUTO_START or DEMAND_START.
    -nkarafSpecifies the service name that will be used when installing the service.
    -d Specifies the display name of the service.
    -D Specifies the description of the service.

Generated files
Copy link

The following files are generated and make up the service wrapper:
  • bin\ServiceName-wrapper[.exe]—the executable file for the wrapper.
  • bin\ServiceName-service[.bat]—the script used to install and remove the service.
  • etc\ServiceName-wrapper.conf—the wrapper's configuration file.
  • Three library files required by the service wrapper:
    • lib\libwrapper.so
    • lib\karaf-wrapper.jar
    • lib\karaf-wrapper-main.jar
Important
The only generated file you should modify is the configuration file.

2.2. Configure the Script
Copy link

Abstract

The service launch script, ServiceName-service[.bat] file, is located under the InstallDir/bin/ directory.

Overview
Copy link

There are a few environment variables you can optionally customize in the ServiceName-service[.bat] file, as described here.

RUN_AS_USER
Copy link

When the RUN_AS_USER variable is set, the ServiceName-service[.bat] script runs as the specified user. For example, to run the script as the user, esbuser, search for the line, #RUN_AS_USER, uncomment the line, and set the variable as follows: 
RUN_AS_USER=esbuser
Copy to Clipboard Toggle word wrap
Important
Make sure that the specified user has the required privileges to write the PID file and wrapper.log files. Failure to be able to write the log file will cause the Wrapper to exit without any way to write out an error message.

PRIORITY
Copy link

(LINUX and UNIX only) You can optionally assign a priority to the launched service using the system nice command by setting the PRIORITY variable (it is not set by default).

2.3. Configuring the Wrapper
Copy link

Abstract

The service wrapper is configured by the ServiceName-wrapper.conf file, which is located under the InstallDir/etc/ directory.

Overview
Copy link

The service wrapper is configured by the ServiceName-wrapper.conf file, which is located under the InstallDir/etc/ directory.
There are several settings you may want to change including:
  • the default environment settings
  • the properties passed to the JVM
  • the classpath
  • the JMX settings
  • the logging settings

Specifying the Red Hat JBoss Fuse's environment
Copy link

A broker's environment is controlled by three environment variables:
  • KARAF_HOME—the location of the Red Hat JBoss Fuse install directory.
  • KARAF_BASE—the root directory containing the configuration and OSGi data specific to the broker instance.
    The configuration for the broker instance is stored in the KARAF_BASE/conf directory. Other data relating to the OSGi runtime is also stored beneath the base directory.
  • KARAF_DATA—the directory containing the logging and persistence data for the broker.
Example 2.1, “Default Environment Settings” shows the default values.

Example 2.1. Default Environment Settings

set.default.KARAF_HOME=InstallDir
set.default.KARAF_BASE=InstallDir
set.default.KARAF_DATA=InstallDir\data
Copy to Clipboard Toggle word wrap

Passing parameters to the JVM
Copy link

If you want to pass parameters to the JVM, you do so by setting wrapper properties using the form wrapper.java.additional.<n>. <n> is a sequence number that must be distinct for each parameter.
One of the most useful things you can do by passing additional parameters to the JVM is to set Java system properties. The syntax for setting a Java system property is wrapper.java.additional.<n>=-DPropName=PropValue.
Example 2.2, “Default Java System Properties” shows the default Java properties.

Example 2.2. Default Java System Properties

# JVM
# note that n is the parameter number starting from 1.
wrapper.java.additional.1=-Dkaraf.home="%KARAF_HOME%"
wrapper.java.additional.2=-Dkaraf.base="%KARAF_BASE%"
wrapper.java.additional.3=-Dkaraf.data="%KARAF_DATA%"
wrapper.java.additional.4=-Dcom.sun.managment.jmxremote
wrapper.java.additional.5=-Dkaraf.startLocalConsole=false
wrapper.java.additional.6=-Dkaraf.startRemoteShell=true
wrapper.java.additional.7=-Djava.endorsed.dirs="%JAVA_HOME%/jre/lib/endorsed;%JAVA_HOME%/lib/endorsed;%KARAF_HOME%/lib/endorsed"
wrapper.java.additional.8=-Djava.ext.dirs="%JAVA_HOME%/jre/lib/ext;%JAVA_HOME%/lib/ext;%KARAF_HOME%/lib/ext"
Copy to Clipboard Toggle word wrap

Adding classpath entries
Copy link

You add classpath entries using the syntax wrapper.java.classpath.<n>. <n> is a sequence number that must be distinct for each classpath entry.
Example 2.3, “Default Wrapper Classpath” shows the default classpath entries.

Example 2.3. Default Wrapper Classpath

wrapper.java.classpath.1=%KARAF_BASE%/lib/karaf-wrapper.jar
wrapper.java.classpath.2=%KARAF_HOME%/lib/karaf.jar
wrapper.java.classpath.3=%KARAF_HOME%/lib/karaf-jaas-boot.jar
wrapper.java.classpath.4=%KARAF_BASE%/lib/karaf-wrapper-main.jar
Copy to Clipboard Toggle word wrap

JMX configuration
Copy link

The default service wrapper configuration does not enable JMX. It does, however, include template properties for enabling JMX. To enable JMX:
  1. Locate the line # Uncomment to enable jmx.
    There are three properties, shown in Example 2.4, “Wrapper JMX Properties”, that are used to configure JMX.

    Example 2.4. Wrapper JMX Properties

    # Uncomment to enable jmx
#wrapper.java.additional.n=-Dcom.sun.management.jmxremote.port=1616
#wrapper.java.additional.n=-Dcom.sun.management.jmxremote.authenticate=false
#wrapper.java.additional.n=-Dcom.sun.management.jmxremote.ssl=false
    Copy to Clipboard Toggle word wrap
  2. Remove the # from in front of each of the properties.
  3. Replace the n in each property to a number that fits into the sequence of addition properties established in the configuration.
You can change the settings to use a different port or secure the JMX connection.
For more information about using JMX see Chapter 14, Configuring JMX.

Configuring logging
Copy link

The wrapper's logging in configured using the properties described in Table 2.2, “Wrapper Logging Properties”.
Expand
Table 2.2. Wrapper Logging Properties
PropertyDescription
wrapper.console.format
Specifies how the logging information sent to the console is formated. The format consists of the following tokens:
  • L—log level
  • P—prefix
  • D—thread name
  • T—time
  • Z—time in milliseconds
  • U—approximate uptime in seconds (based on internal tick counter)
  • M—message
wrapper.console.loglevelSpecifies the logging level displayed on the console.
wrapper.logfileSpecifies the file used to store the log.
wrapper.logfile.formatSpecifies how the logging information sent to the log file is formated.
wrapper.console.loglevelSpecifies the logging level sent to the log file.
wrapper.console.maxsizeSpecifies the maximum size, in bytes, that the log file can grow to before the log is archived. The default value of 0 disables log rolling.
wrapper.console.maxfilesSpecifies the maximum number of archived log files which will be allowed before old files are deleted. The default value of 0 implies no limit.
wrapper.syslog.loglevelSpecifies the logging level for the sys/event log output.
For more information about Red Hat JBoss Fuse logging see Chapter 17, Logging.

2.4. Installing and Starting the Service
Copy link

Overview
Copy link

The operating system determines the exact steps using to complete the installation of Red Hat JBoss Fuse as a service. The wrapper:install command provides basic instructions for your operating system.

Windows
Copy link

To install the service run InstallDir\bin\ServiceName-service.bat install. If you used the default start setting, the service will start when Windows is launched. If you specified DEMAND_START, you will need to start the service manually.
To start the service manually run net start "ServiceName". You can also use the Windows service UI.
To manually stop the service run net stop "ServiceName" You can also use the Windows service UI.
You remove the installed the service by running InstallDir\bin\ServiceName-service.bat remove.

Redhat Linux
Copy link

To install the service and configure it to start when the machine boots, run the following commands: 
# ln -s InstallDir/bin/ServiceName-service /etc/init.d/
# chkconfig ServiceName-service --add
# chkconfig ServiceName-service on
Copy to Clipboard Toggle word wrap
To start the service manually run service ServiceName-service start.
To manually stop the service run service ServiceName-service stop.
You remove the installed the service by running the following commands: 
#service ServiceName-service stop
# chkconfig ServiceName-service --del
# rm /etc/init.d/ServiceName-service
Copy to Clipboard Toggle word wrap

Ubuntu Linux
Copy link

To install the service and configure it to start when the machine boots, run the following commands: 
# ln -s InstallDir/bin/ServiceName-service /etc/init.d/
# update-rc.d ServiceName-service defaults
Copy to Clipboard Toggle word wrap
To start the service manually run /etc/init.d/ServiceName-service start.
To manually stop the service run /etc/init.d/ServiceName-service stop.
You remove the installed the service by running the following commands: 
#/etc/init.d/ServiceName-service stop
# rm /etc/init.d/ServiceName-service
Copy to Clipboard Toggle word wrap

Chapter 3. Basic Security
Copy link

Abstract

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

3.1. Configuring Basic Security
Copy link

Overview
Copy link

The Red Hat JBoss Fuse 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 Red Hat JBoss Fuse runtime is remotely inaccessible by default.
If you want to access the runtime remotely, you must first customize the security configuration, as described here.

Before you start the container
Copy link

If you want to enable remote access to the JBoss Fuse container, perform the following configuration steps before starting the container:
  1. Create a secure JAAS user.
  2. Configure the Apache ActiveMQ Web console (optional).

Create a secure JAAS user
Copy link

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
Copy to Clipboard Toggle word wrap
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. For more details about JAAS, see Chapter 15, Configuring JAAS Security.
Warning
It is strongly recommended that you define custom user credentials with a strong password.
If you want to access the Apache ActiveMQ Web console (for remote administration of JMS messaging), you must provide the Web console servlet with the credentials it needs to login to the JMS broker.
Edit the InstallDir/etc/system.properties file. Search for the activemq.jmx.user and activemq.jmx.password settings (which are commented out by default), and modify them as follows: 
#
# Authentication - must match an entry in user.properties with the admin privilege
#
activemq.jmx.user=Username
activemq.jmx.password=Password
Copy to Clipboard Toggle word wrap
Where the Username and Password are the credentials of a JAAS user with admin privileges.
Note
Indirectly, these properties are used to set the webconsole.jmx.* and webconsole.jms.* properties (in the InstallDir/etc/system.properties file).

Ports exposed by the Red Hat JBoss Fuse container
Copy link

Figure 3.1, “Ports Exposed by the Red Hat JBoss Fuse Container” shows the ports exposed by the JBoss Fuse container by default.

Figure 3.1. Ports Exposed by the Red Hat JBoss Fuse 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 SSL.
  • 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 Jetty container that can host Web console servlets. By default, the Web consoles are not installed in the container.

Enabling the remote console port
Copy link

You can access the remote console port whenever both of the following conditions are true:
  • JAAS is configured with at least one set of login credentials.
  • The JBoss Fuse 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
Copy to Clipboard Toggle word wrap
Where the Username and Password are the credentials of a JAAS user with admin privileges. For more details, see Chapter 9, Using Remote Connections to Manage a Container.

Strengthening security on the remote console port
Copy link

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

Enabling the JMX port
Copy link

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
Copy to Clipboard Toggle word wrap
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.

Enabling the Web console port
Copy link

All of the Web consoles are installed as servlets in the container's embedded Jetty container. The Web consoles share the same HTTP server port, which is powered by Jetty. You can optionally enable the following Web consoles in JBoss Fuse:
  • Karaf Web console—is not installed by default. To enable the Karaf Web console, perform the following steps:
    1. In a running JBoss Fuse instance (see Section 4.1, “Starting Red Hat JBoss Fuse”), enter the following console command: 
      JBossFuse:karaf@root> features:install webconsole
      Copy to Clipboard Toggle word wrap
    2. In a Web browser, navigate to the following URL: 
      http://localhost:8181/system/console
      Copy to Clipboard Toggle word wrap
    3. The browser will prompt you to log on. Enter valid JAAS user credentials to access the console.
  • Apache ActiveMQ Web console—is not installed by default. To enable the Apache ActiveMQ Web console, perform the following steps:
    1. Make sure that you have already configured the container's Java system properties, as described in the section called “Configure the Apache ActiveMQ Web console (optional)”.
      Note
      The Apache ActiveMQ Web console has a three tier architecture, as shown in Figure 3.1, “Ports Exposed by the Red Hat JBoss Fuse Container”. The credentials provided in this step enable the middle tier (the Web console servlet) to log on to the back-end tier (the Apache ActiveMQ broker).
    2. In a running JBoss Fuse instance, enter the following console command: 
      JBossFuse:karaf@root> features:install mq-web-console
      Copy to Clipboard Toggle word wrap
    3. In a Web browser, navigate to the following URL: 
      http://localhost:8181/activemqweb
      Copy to Clipboard Toggle word wrap
    4. The browser will prompt you to log on. Enter valid JAAS user credentials to access the console.

Strengthening security on the Web console port
Copy link

The Karaf Web console is already secured by JAAS authentication. To add SSL security, see chapter "Securing the Web Console" in "Security Guide".

3.2. Disabling Broker Security
Copy link

Overview
Copy link

Prior to Fuse ESB Enterprise version 7.0.2, the Apache ActiveMQ broker was insecure (JAAS authentication not enabled). This section explains how to revert the Apache ActiveMQ broker to an insecure mode of operation, so that it is unnecessary to provide credentials when connecting to the broker.
Warning
After performing the steps outlined in this section, the broker has no protection against hostile clients. This type of configuration is suitable only for use on internal, trusted networks.

Standalone server
Copy link

These instructions assume that you are running Red Hat JBoss Fuse in standalone mode (that is, running in an OSGi container, but not using Fuse Fabric). In your installation of JBoss Fuse, open the InstallDir/etc/activemq.xml file using a text editor and look for the following lines: 
...
<plugins>
 <jaasAuthenticationPlugin configuration="karaf" />
</plugins>
...
Copy to Clipboard Toggle word wrap
To disable JAAS authentication, delete (or comment out) the jaasAuthenticationPlugin element. The next time you start up the Red Hat JBoss Fuse container (using the InstallDir/bin/fusemq script), the broker will run with unsecured ports.

Abstract

Red Hat JBoss Fuse provides simple command-line tools for starting and stopping the server.

4.1. Starting Red Hat JBoss Fuse
Copy link

Abstract

The default way for deploying the Red Hat JBoss Fuse 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.

Overview
Copy link

The default way for deploying the Red Hat JBoss Fuse runtime is to deploy it as a standalone server with an active console. You can also deploy the runtime to run as a background process without a console.

Setting up your environment
Copy link

You can start the JBoss Fuse runtime from the installation directory without doing any work. However, if you want to start it in a different folder you will need to add the bin directory of your JBoss Fuse installation to the PATH environment variable, as follows:
Windows
set PATH=%PATH%;InstallDir\bin
*NIX
export PATH=$PATH,InstallDir/bin

Launching the runtime
Copy link

If you are launching the JBoss Fuse runtime from the installation directory use the following command:
Windows
*NIX
If JBoss Fuse starts up correctly you should see the following on the console: 
 _ ____ ______ | | _ \ | ____| | | |_) | ___ ___ ___ | |__ _ _ ___ ___ _ | | _ / _ \/ __/ __| | __| | | / __|/ _ \ | |__| | |_) | (_) \__ \__ \ | | | |_| \__ \ __/ \____/|____/ \___/|___/___/ |_| \__,_|___/\___| JBoss Fuse (6.0.0.redhat-xxx) http://www.redhat.com/products/jbossenterprisemiddleware/fuse/ Hit '<tab>' for a list of available commands and '[cmd] --help' for help on a specific command. Hit '<ctrl-d>' or 'osgi:shutdown' to shutdown JBoss Fuse. JBossFuse:karaf@root>
Copy to Clipboard Toggle word wrap

Launching the runtime in server mode
Copy link

Launching in server mode runs Red Hat JBoss Fuse in the background, without a local console. You would then connect to the running instance using a remote console. See Section 9.2, “ Connecting and Disconnecting Remotely” for details.
To launch JBoss Fuse in server mode, run the following
Windows
*NIX 
bin/fuse server
Copy to Clipboard Toggle word wrap
Alternatively, you can launch JBoss Fuse in server mode using the start script in the InstallDir/bin directory.

Launching the runtime in client mode
Copy link

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

4.2. Stopping Red Hat JBoss Fuse
Copy link

You can stop an instance of Red Hat JBoss Fuse either from within a console, or using a stop script.

Stopping an instance from a local console
Copy link

If you launched Red Hat JBoss Fuse by running fuse or fuse client, you can stop it by doing one of the following at the karaf> prompt:
  • Type shutdown -f
  • Press Ctrl+D

Stopping an instance running in server mode
Copy link

If you launched Red Hat JBoss Fuse by running fuse server or by running the start script, you can stop it remotely, as described in Section 9.3, “Stopping a Remote Container”.
Alternatively, you can log on to the host where the instance is running and run one of the following from the InstallDir/bin directory:
  • ./admin stop instanceName
  • ./stop
Note
If the sshHost property in etc/org.apache.karaf.shell.cfg is set to the default value of 0.0.0.0, you can run the stop script without any arguments. However, if you have configured a different hostname, you must run stop -h hostname.

Abstract

The management console an be installed directly into any Apache Karaf container using the feature mechanism.
The management console can be installed into any Apache Karaf container. Standalone containers install it using the feature mechanism. Fabric containers install it by applying the management console's standard profile to one of the containers in the fabric.
In a standalone container, you will need to either create a new fabric for the console to manage or have the server join an existing fabric.
When the management console is installed into a Fabric container, the console is automatically configured to manage the fabric to which the container belongs.

5.1. Installing into a Standalone Container
Copy link

Procedure
Copy link

To install the management console into a standalone container:
  1. Open the container's command console.
  2. Check if the prerequisites are installed using the features:list command.
  3. If any of the prerequisites are not installed, install them using the features:install command.
  4. Install the management console using the features:install command shown in Example 5.1, “Installing the Management Console”.

    Example 5.1. Installing the Management Console

    >features:install fabric-webui
    Copy to Clipboard Toggle word wrap
  5. In your Web browser, open the management console.
    The management console will be hosted at the container's HTTP service port as specified by the org.ops4j.pax.web PID's org.osgi.service.http.port property. The default HTTP port for an Apache Karaf container is 8181.
  6. Connect the console to a Fabric.
    • Join an existing fabric.
      1. Click Join.
        A form opens where you enter a fabric server's connection information.
      2. In the Hostname field, enter the name of the machine hosting fabric server for the fabric the console will manage.
      3. In the Port field, enter the port number used to connect to the fabric server for the fabric the console will manage.
      4. In the ZooKeeper Password field, enter the password used to access the registry data for the fabric the console will manage.
      5. Click Join.
        The management connects to the fabric and the login page appears.
    • Create a new fabric.
      1. Click Create.
        A form opens where you enter the information needed to create a new fabric.
      2. In the Username field, enter the name of the user for accessing the console and be used to connect to all of the container's in the fabric.
      3. In the Password field, enter the password for the administrative user.
      4. In the ZooKeeper Password field, enter the password that will be used to secure access to the fabric's registry data.
      5. In the Global Resolver field, select the default policy governing how containers in the fabric report their address to other containers.
      6. In the Local Resolver field, select the policy governing how the container being created reports its address to other containers.
      7. Enter a range of ports over which the fabric can be contacted.
      8. Click Create.
        The console's server creates the fabric and the login page appears.

5.2. Installing into a Fabric Container
Copy link

Overview
Copy link

The fmc profile configures a container to become a management console server. You only need to apply the profile to one container in a fabric to enable the management console.

Procedure
Copy link

To install the management console into a Fabric Container:
  1. Open a command console for one of the containers in the fabric.
  2. Install the management console's profile using the fabric:container-add-profile command shown in Example 5.2, “Installing the Management Console Profile”.

    Example 5.2. Installing the Management Console Profile

    >fabric:container-add-profile containerName fmc
    Copy to Clipboard Toggle word wrap
    containerName is the name of the container into which the management console will be installed
  3. In your Web browser, open the management console.
    The console will be hosted at the container's HTTP service port. To determine the container's HTTP service port:
    1. Connect to the container into which you deployed the fmc profile using the fabric:container-connect command.
    2. Use the config:list command to see the container's configuration.
    3. Locate the org.ops4j.pax.web PID.
    4. See the value assigned to the org.osgi.service.http.port property.
    If the org.osgi.service.http.port is not set for this container, you can set it by adding the property to the fmc profile as shown in Example 5.3, “Setting a Fabric Container's HTTP Port”.

    Example 5.3. Setting a Fabric Container's HTTP Port

    > fabric:profile-edit -p org.ops4j.pax.web/org.osgi.service.http.port=portNumber fmc
    Copy to Clipboard Toggle word wrap
Revision History
11/28/12
Updated to use fabric configuration

Abstract

By default the connection to the management console server is unencrypted. To use a secure connection you must configure it to use HTTPS.

Overview
Copy link

Out of the box the management console is configured to use an unencrypted connection. This makes it easy to demo and use in testing environments. However, it is not suitable for use in production environments.
To enable HTTPS, you need to create and install X.509 certificates and keys for the console. You must also enable the management console to use HTTPS.

Creating certificates
Copy link

Before you can enable SSL, you must create an X.509 certificate and private key for the console. The certificate and private key must be in Java keystore format.

Installing the certificates
Copy link

The recommended location to install the certificates for the console is in the management console's etc/certs folder. You can, however, store the certificates in any folder from which the container can access them.
Note
You will need the location to configure the management console.

Enabling HTTPS
Copy link

The management console's HTTP port is configured using the org.ops4j.pax.web PID. To enable HTTPS, you will need to change the properties in that PID for the container in which the management console is running. You can do this is to update the fmc profile deployed to the container. Alternatively, you could create a separate profile to configure the HTTP port.
To enable HTTPS by modifying the fmc profile:
  1. Open a command console connected to one of the container in the fabric.
  2. Disable the insecure HTTP port setting the org.osgi.service.http.enabled property to false as shown in Example 5.4, “Disabling the HTTP Port”.

    Example 5.4. Disabling the HTTP Port

    fabric:profile-edit -p org.ops4j.pax.web/org.osgi.service.http.enabled=false fmc
    Copy to Clipboard Toggle word wrap
  3. Enable the secure HTTPS port by setting the org.osgi.service.http.secure.enabled property to true as shown in Example 5.5, “Property for Enabling the HTTPS Port”.

    Example 5.5. Property for Enabling the HTTPS Port

    fabric:profile-edit -p org.ops4j.pax.web/org.osgi.service.http.secure.enabled=true fmc
    Copy to Clipboard Toggle word wrap
  4. Specify the port used for connecting over HTTPS by setting the org.osgi.service.http.port.secure property to an available port as shown in Example 5.6, “Property for Specifying the HTTPS Port”.

    Example 5.6. Property for Specifying the HTTPS Port

    fabric:profile-edit -p org.ops4j.pax.web/org.osgi.service.http.port.secure=8108 fmc
    Copy to Clipboard Toggle word wrap
    Note
    You can reuse port 8107.
  5. Configure the keystore used to hold the X.509 certificates.
    1. Specify the location of the keystore by adding the org.ops4j.pax.web.ssl.keystore property.
    2. Specify the type of keystore used by adding the org.ops4j.pax.web.ssl.keystore.type property and setting it to JKS.
    3. Specify the password for unlocking the Java keystore by adding the org.ops4j.pax.web.ssl.password property.
    4. Specify the password for decrypting the private key by adding the org.ops4j.pax.web.ssl.keypassword property.
      Note
      This is typically the same as the password used to unlock the keystore.
    5. Specify if certificate-based client authentication at the server is wanted by adding the org.ops4j.pax.web.ssl.clientauthwanted property.
      When set to true the server will request that the client send an X.509 certificate during the SSL handshake.
    6. Specify if certificate-based client authentication at the server is required by adding the org.ops4j.pax.web.ssl.clientauthneeded property.
      When set to true an exception is thrown if the client does not present a valid X.509 certificate during the SSL handshake.

Chapter 6. Creating a New Fabric
Copy link

Abstract

When there are no existing fabric's to join, or you want to start a new fabric, you can create a new one from a standalone container.

Overview
Copy link

A fabric consists of two different kinds of container:
Fabric Server
A Fabric Server has a special status in the fabric, because it is responsible for maintaining a replica of the fabric registry. In each Fabric Server, a registry service is installed. The registry service (based on Apache ZooKeeper) maintains a replica of the registry database and provides a ZooKeeper server, which ordinary agents can connect to in order to retrieve registry data.
Fabric Container
A Fabric Container is aware of the locations of all of the Fabric Servers, and it can retrieve registry data from any Fabric Server in the Fabric Ensemble. A Fabric Agent is installed in each Fabric Container. The Fabric Agent actively monitors the fabric registry, and whenever a relevant modification is made to the registry, it immediately updates its container to keep the container consistent with the registry settings.

Fabric Ensemble
Copy link

A Fabric Ensemble is a collection of Fabric Servers and Fabric Containers that collectively maintain the state of the fabric registry. The Fabric Ensemble implements a replicated database and uses a quorum-based voting system to ensure that data in the fabric registry remains consistent across all of the fabric's containers. To guard against network splits in a quorum-based system, it is a requirement that the number of Fabric Servers in a Fabric Ensemble is always an odd number.
The number of Fabric Servers in a fabric is typically 1, 3, or 5. A fabric with just one Fabric Server is suitable for experimentation only. A live production system should have at least 3 or 5 Fabric Servers, installed on separate hosts, to provide fault tolerance.

Procedure
Copy link

To create a new fabric from a standalone container:
  1. Connect to the standalone container's command console.
  2. Any existing users in the InstallDir/etc/users.properties file are automatically used to initialize the fabric's user data, when you create the fabric. This provides a convenient way to initialize the fabric's user data.
    If you have not already done so, it is recommended that you populate the users.properties file, by adding one or more lines of the following form: 
    Username=Password[,RoleA][,RoleB]...
    Copy to Clipboard Toggle word wrap
    At least one of the users must have the admin role, to enable administration of the fabric. For example: 
    admin=secretpassword,admin
    Copy to Clipboard Toggle word wrap
  3. Assuming that some users are already defined in the users.properties file, you can create a new fabric by entering the following command: 
    JBossFuse:karaf@root> fabric:create --zookeeper-password admin
    Copy to Clipboard Toggle word wrap
    The current container (named root by default) becomes a Fabric Server with a registry service installed. Initially, this is the only container in the fabric. The Zookeeper password is used to protect sensitive data in the Fabric registry service (all of the nodes under /fabric).
    Note
    If you want to import a predefined set of profiles, use the -p import-dir option to specify the set of profiles to import.
    For more details on fabric:create see section "Description" in "Console Reference".
  4. (Alternative) If no users are predefined in the users.properties file, an alternative approach is to define a new user at the same time the fabric is created, by supplying the --new-user and --new-user-password options, as follows: 
    JBossFuse:karaf@root> fabric:create --new-user jdoe --new-user-password secretpassword --zookeeper-password admin
    Copy to Clipboard Toggle word wrap
    The new user, jdoe, is automatically assigned the admin role, which gives the user full administration privileges.

Fabric creation process
Copy link

Several things happen when a fabric is created from a standalone container:
  1. The container installs the requisite OSGi bundles to become a Fabric Server.
  2. The Fabric Server starts a registry service, which listens on IP port 2181 (which makes fabric configuration data available to all of the containers in the fabric).
  3. The Fabric Server installs a new JAAS realm (based on the ZooKeeper login module), which overrides the default JAAS realm and stores its user data in the ZooKeeper registry.
  4. The new Fabric Ensemble consists of a single Fabric Server (the current container).
  5. A default set of profiles is imported from InstallDir/fabric/import (can optionally be overridden).
  6. After the standalone container is converted into a Fabric Server, the previously installed OSGi bundles and Karaf features are completely cleared away and replaced by the default Fabric Server configuration. For example, some of the shell command sets that were available in the standalone container are no longer available in the Fabric Server.

Chapter 7. Joining a Fabric
Copy link

Overview
Copy link

Any standalone container can be joined to an existing fabric using the fabric:join console command. You need to supply the URL of one of the Fuse Servers in the fabric and the standalone container is then added to the fabric. The container can join the fabric as either a managed container or a non-managed container:
  • A managed container is a full member of the fabric and is managed by a Fabric Agent. The agent configures the container based on information provided by the fabric's ensemble. The ensemble knows which profiles are associated with the container and the agent determines what to install based on the contents of the profiles.
  • A non-managed container is not managed by a Fabric Agent. Its configuration remains intact after it joins the fabric and is controlled as if the container were a standalone container. Joining the fabric in this manner registers the container with the fabric's ensemble and allows clients to locate the services running in the container using the fabric's discovery mechanism.

Joining a fabric as a managed container
Copy link

The default behavior of the fabric:join command is to wipe out the container's configuration and replace it with the fabric profile. If you want to preserve the previous configuration of the container, however, you must ensure that the fabric has an appropriately configured profile, which you can deploy into the container after it joins the fabric.
The fabric:join command's -p option enables you to specify a profile to install into the container once the agent is installed.
For details of how to create and edit a profile, see section "Create Fabric Profiles" in "Getting Started", , and .

Joining a fabric as an non-managed container
Copy link

When a container joins a fabric as a non-managed container, its deployment mechanisms continue to function like a standalone container (based on osgi:install, features:install, and hot deployment), because a Fabric Agent does not take control of its configuration. The agent only registers the container with the fabric's ensemble and keeps the registry entries for it up to date. This enables the newly joined container to discover services running in the container (through Fabric's discovery mechanisms) and to administer these services.
Joining a fabric as an non-managed container is a convenient approach to take when you want to use your local container as a console to administer a fabric. For example, this is an approach that is typically taken with the Fuse Management Console (FMC).

How to join a fabric
Copy link

To join a container to a fabric, perform the following steps:
  1. Get the registry service URL for one of the Fabric Servers in the existing fabric. The registry service URL has the following format: 
    Hostname[:IPPort]
    Copy to Clipboard Toggle word wrap
    Normally, it is sufficient to specify just the hostname, Hostname, because the registry service uses the fixed port number, 2182, by default. In exceptional cases, you can discover the registry service port by following the instructions in the section called “How to discover the URL of a Fabric Server”.
  2. Get the ZooKeeper password for the fabric. An administrator can access the fabric's ZooKeeper password at any time, by entering the following console command (while logged into one of the Fabric Containers): 
    JBossFuse:karaf@root> fabric:ensemble-password
    Copy to Clipboard Toggle word wrap
  3. Connect to the standalone container's command console.
  4. Join a container in one of the following ways:
    • Join as a managed container, with a default profile—uses the fabric profile. 
      JBossFuse:karaf@root> fabric:join --zookeeper-password ZooPass URL ContainerName
      Copy to Clipboard Toggle word wrap
    • Join as a managed container, specifying a custom profile—uses a custom profile. 
      JBossFuse:karaf@root> fabric:join --zookeeper-password ZooPass -p Profile URL ContainerName
      Copy to Clipboard Toggle word wrap
    • Join as a non-managed container—preserves the existing container configuration. 
      JBossFuse:karaf@root> fabric:join -n --zookeeper-password ZooPass URL ContainerName
      Copy to Clipboard Toggle word wrap
    Where you can specify the following values:
    ZooPass
    The existing fabric's ZooKeeper password.
    URL
    The URL for one of the fabric's registry services (usually just the hostname where a Fabric Server is running).
    ContainerName
    The new name of the container when it registers itself with the fabric.
    Warning
    If the container your're adding to the fabric has the same name as a container already registered with the fabric, both containers will be reset and will always share the same configuration.
    Profile
    The name of the custom profile to install into the container after it joins the fabric (managed container only).
  5. If you joined the container as a managed container, you can subsequently deploy a different profile into the container using the fabric:container-change-profile console command.

How to discover the URL of a Fabric Server
Copy link

If you suspect that a Fabric Server is not using the default IP port, 2181, for its registry service, you can discover the port as follows:
  1. Connect to the command console of one of the containers in the fabric.
  2. Enter the following sequence of console commands: 
    JBossA-MQ:karaf@root> config:edit org.fusesource.fabric.zookeeper
JBossA-MQ:karaf@root> config:proplist
   service.pid = org.fusesource.fabric.zookeeper
   zookeeper.url = myhostA:2181,myhostB:2181,myhostC:2181,myhostC:2182,myhostC:2183
   fabric.zookeeper.pid = org.fusesource.fabric.zookeeper
JBossA-MQ:karaf@root> config:cancel
    Copy to Clipboard Toggle word wrap
    The zookeeper.url property holds a comma-separated list of Fabric Server URLs. You can use any one of these URLs to join the fabric.

Chapter 8. Shutting Down a Fabric
Copy link

Overview
Copy link

This chapter describes how to shut down part or all of a fabric. In particular, when shutting down the ensemble servers (Fabric Servers), special care is needed.

Shutting down a managed container
Copy link

From the console, you can shut down a managed container at any time using the fabric:container-stop command, specifying the name of the managed container—for example: 
fabric:container-stop ManagedContainerName
Copy to Clipboard Toggle word wrap
The fabric:container-stop command looks up the container name in the registry and retrieves the data it needs to shut down that container. This approach works no matter where the container is deployed: whether on a remote host or in a cloud.

Shutting down a Fabric Server
Copy link

Occasionally, you might want to shut down a Fabric Server for maintenance reasons. It is possible to do this without disabling the fabric, as long as you ensure more than half of the Fabric Servers in the ensemble remain up and running.
For example, if you have an ensemble consisting of three servers, registry1, registry2, and registry3, you can shut down at most one of these Fabric Servers at a time using the fabric:container-stop command—for example: 
fabric:container-stop registry3
Copy to Clipboard Toggle word wrap
After performing the necessary maintenance, you can restart the Fabric Server as follows: 
fabric:container-start registry3
Copy to Clipboard Toggle word wrap

Shutting down an entire fabric
Copy link

In a production environment, it is rarely ever necessary to shut down an entire fabric. The idea of a fabric is that it provides redundancy, enabling you to shut down part of the fabric and restart it without having to shut down the whole fabric. You can even apply patches to a fabric without shutting down containers.
If you do need to shut down an entire fabric, however, you can do so as follows:
  1. To take a concrete example, consider a fabric which consists of the following containers:
    • Three Fabric Servers (ensemble servers): registry1, registry2, registry3.
    • Four managed containers: managed1, managed2, managed3, managed4.
  2. Use the client console utility to log on to one of the containers in the fabric. Because this will be the last container to shut down, it is convenient to choose one of the Fabric Servers. For example, to log on to the registry1 server, enter the following command: 
    ./client -u AdminUser -p AdminPass -h Registry1Host
    Copy to Clipboard Toggle word wrap
    Where Registry1Host is the host where registry1 is running and AdminUser and AdminPass are the credentials of a user with administration privileges. It is assumed that the registry1 server is listening for console connections on the default IP port (that is, 8101)
  3. Shut down all of the managed containers in the fabric, using the fabric:container-stop command—for example: 
    fabric:container-stop managed1
fabric:container-stop managed2
fabric:container-stop managed3
fabric:container-stop managed4
    Copy to Clipboard Toggle word wrap
  4. Remove all but one of the Fabric Servers from the ensemble, using the fabric:ensemble-remove command. For example, given the ensemble consisting of registry1, registry2, and registry3 (where you are logged on to registry1), remove registry2 and registry3 from the ensemble as follows: 
    fabric:ensemble-remove registry2 registry3
    Copy to Clipboard Toggle word wrap
  5. You can now shut down the registry2 and registry3 containers using the fabric:container-stop command, as follows: 
    fabric:container-stop registry2
fabric:container-stop registry3
    Copy to Clipboard Toggle word wrap
  6. Assuming you are logged on to registry1 (the sole remaining Fabric Server), shut it down as follows: 
    shutdown -f
    Copy to Clipboard Toggle word wrap
  7. Whenever you restart the fabric, you will have to remember to recreate the ensemble, so that it consists of three Fabric Servers again. For example, to recreate the ensemble consisting of registry1, registry2, and registry3, you would restart the three servers, and then enter the following command: 
    fabric:ensemble-add registry2 registry3
    Copy to Clipboard Toggle word wrap

Note on shutting down the ensemble
Copy link

If you are logged on to a container that is connected to a fabric, the following obvious procedure for shutting down the fabric ensemble does not work: 
fabric:container-stop registry1
fabric:container-stop registry2
fabric:container-stop registry3
Copy to Clipboard Toggle word wrap
The third invocation of fabric:container-stop will fail and throw an error. This is because of the quorum-based voting system used by the ensemble (which is designed to protect against network splits). After the first two Fabric servers (registry1 and registry2) are shut down, fewer than half of the ensemble servers are available. At this point, the registry shuts down and refuses to service any more requests, because there is no longer a quorum of ensemble servers available (that is, fewer than 50% of the ensemble servers are available). This causes a problem for the fabric:container-stop command, which normally contacts the registry to retrieve details about the container it is trying to shut down.
The solution to this problem is to adopt the procedure described in the section called “Shutting down an entire fabric”, where you first reduce the size of the ensemble using fabric:ensemble-remove, before attempting to shut down the ensemble servers.
Revision History
09/10/12
Moved Child Container to separate chapter
09/10/12
Removed Karaf language

Abstract

It does not always make sense to use a local console to manage a container. Red Hat JBoss Fuse has a number of ways of remotely managing a container. You can use a remote container's command console or start a remote client.

9.1. Configuring a Container for Remote Access
Copy link

Overview
Copy link

When you start the Red Hat JBoss Fuse runtime in default mode or in server mode, it enables a remote console that can be accessed over SSH from any other JBoss Fuse console. The remote console provides all of the functionality of the local console and allows a remote user complete control over the container and the services running inside of it.
Note
When run in client mode the JBoss Fuse runtime disables the remote console.

Configuring a container for remote access
Copy link

The SSH hostname and port number are configured in the InstallDir/etc/org.apache.karaf.shell.cfg configuration file. Example 9.1, “Changing the Port for Remote Access” shows a sample configuration that changes the port used to 8102.

Example 9.1. Changing the Port for Remote Access

sshPort=8102
sshHost=0.0.0.0
Copy to Clipboard Toggle word wrap

9.2.  Connecting and Disconnecting Remotely
Copy link

Abstract

There are two alternative ways of connecting to a remote container. If you are already running an Red Hat JBoss Fuse command shell, you can invoke a console command to connect to the remote container. Alternatively, you can run a utility directly on the command-line to connect to the remote container.
Overview
Copy link
Any container's command console can be used to access a remote container. Using SSH, the local container's console connects to the remote container and functions as a command console for the remote container.
Using the ssh:ssh console command
Copy link
You connect to a remote container's console using the ssh:ssh console command.

Example 9.2. ssh:ssh Command Syntax

ssh:ssh { -l username } { -P password } { -p port } { hostname }

-l username
The username used to connect to the remote container. Use valid JAAS login credentials that have admin privileges (see Chapter 15, Configuring JAAS Security).
-P password
The password used to connect to the remote container.
-p port
The SSH port used to access the desired container's remote console.
By default this value is 8101. See the section called “Configuring a container for remote access” for details on changing the port number.
hostname
The hostname of the machine that the remote container is running on. See the section called “Configuring a container for remote access” for details on changing the hostname.
Warning
We recommend that you customize the username and password in the etc/users.properties file. See Chapter 15, Configuring JAAS Securityfor details.

Example 9.3. Connecting to a Remote Console

JBossFuse:karaf@root>ssh:ssh -l smx -P smx -p 8108 hostname
Copy to Clipboard Toggle word wrap
To confirm that you have connected to the correct container, type shell:info at the prompt. Information about the currently connected instance is returned, as shown in Example 9.4, “Output of the shell:info Command”.

Example 9.4. Output of the shell:info Command

Karaf Karaf version 2.2.5.fuse-beta-7-052 Karaf home /Volumes/ESB/jboss-fuse-full-6.0.0.redhat-0XX Karaf base /Volumes/ESB/jboss-fuse-full-6.0.0.redhat-0XX/instances/child1 OSGi Framework org.apache.felix.framework - 4.0.3.fuse-beta-7-052 JVM Java Virtual Machine Java HotSpot(TM) 64-Bit Server VM version 20.6-b01-415 Version 1.6.0_31 Vendor Apple Inc. Uptime 6 minutes Total compile time 24.048 seconds Threads Live threads 62 Daemon threads 43 Peak 287 Total started 313 Memory Current heap size 78,981 kbytes Maximum heap size 466,048 kbytes Committed heap size 241,920 kbytes Pending objects 0 Garbage collector Name = 'PS Scavenge', Collections = 11, Time = 0.271 seconds Garbage collector Name = 'PS MarkSweep', Collections = 1, Time = 0.117 seconds Classes Current classes loaded 5,720 Total classes loaded 5,720 Total classes unloaded 0 Operating system Name Mac OS X version 10.7.3 Architecture x86_64 Processors 2
Copy to Clipboard Toggle word wrap
Disconnecting from a remote console
Copy link
To disconnect from a remote console, enter logout or press Ctrl+D at the prompt.
You will be disconnected from the remote container and the console will once again manage the local container.
Using the remote client
Copy link
The remote client allows you to securely connect to a remote Red Hat JBoss Fuse container without having to launch a full JBoss Fuse container locally.
For example, to quickly connect to a JBoss Fuse instance running in server mode on the same machine, open a command prompt and run the client[.bat] script (which is located in the InstallDir/bin directory), as follows: 
client
Copy to Clipboard Toggle word wrap
More usually, you would provide a hostname, port, username, and password to connect to a remote instance. If you were using the client within a larger script, for example in a test suite, you could append console commands as follows: 
client -a 8101 -h hostname -u username -p password shell:info
Copy to Clipboard Toggle word wrap
Alternatively, if you omit the -p option, you will be prompted to enter a password.
For a standalone container, use any valid JAAS user credentials that have admin privileges.
For a container in a fabric, the default username and password is admin and admin.
To display the available options for the client, type: 
client --help
Copy to Clipboard Toggle word wrap

Example 9.5. Karaf Client Help

Apache Felix Karaf client -a [port] specify the port to connect to -h [host] specify the host to connect to -u [user] specify the user name -p [password] specify the password --help shows this help message -v raise verbosity -r [attempts] retry connection establishment (up to attempts times) -d [delay] intra-retry delay (defaults to 2 seconds) [commands] commands to run If no commands are specified, the client will be put in an interactive mode
Copy to Clipboard Toggle word wrap
Disconnecting from a remote client console
Copy link
If you used the remote client to open a remote console, as opposed to using it to pass a command, you will need to disconnect from it. To disconnect from the remote client's console, enter logout or press Ctrl+D at the prompt.
The client will disconnect and exit.
Overview
Copy link
You can also use the ssh command-line utility (a standard utility on UNIX-like operating systems) to log in to the Red Hat JBoss Fuse container, where the authentication mechanism is based on public key encryption (the public key must first be installed in the container). For example, given that the container is configured to listen on IP port 8101, you could log in as follows: 
ssh -p 8101 jdoe@localhost
Copy to Clipboard Toggle word wrap
Important
Key-based login is currently supported only on standalone containers, not on Fabric containers.
Prerequisites
Copy link
To use key-based SSH login, the following prerequisites must be satisfied:
Default key location
Copy link
The ssh command automatically looks for the private key in the default key location. It is recommended that you install your key in the default location, because it saves you the trouble of specifying the location explicitly.
On a *NIX operating system, the default locations for an RSA key pair are: 
~/.ssh/id_rsa
~/.ssh/id_rsa.pub
Copy to Clipboard Toggle word wrap
On a Windows operating system, the default locations for an RSA key pair are: 
C:\Documents and Settings\Username\.ssh\id_rsa
C:\Documents and Settings\Username\.ssh\id_rsa.pub
Copy to Clipboard Toggle word wrap
Note
Red Hat JBoss Fuse supports only RSA keys. DSA keys do not work.
Creating a new SSH key pair
Copy link
Generate an RSA key pair using the ssh-keygen utility. Open a new command prompt and enter the following command: 
ssh-keygen -t rsa -b 2048
Copy to Clipboard Toggle word wrap
The preceding command generates an RSA key with a key length of 2048 bits. You will then be prompted to specify the file name for the key pair: 
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/Username/.ssh/id_rsa):
Copy to Clipboard Toggle word wrap
Type return to save the key pair in the default location. You will then be prompted for a pass phrase: 
Enter passphrase (empty for no passphrase):
Copy to Clipboard Toggle word wrap
You can optionally enter a pass phrase here or type return twice to select no pass phrase.
Note
If you want to use the same key pair for running Fabric console commands, it is recommended that you select no pass phrase, because Fabric does not support using encrypted private keys.
Installing the SSH public key in the container
Copy link
To use the SSH key pair for logging into the Red Hat JBoss Fuse container, you must install the SSH public key in the container by creating a new user entry in the InstallDir/etc/keys.properties file. Each user entry in this file appears on a single line, in the following format: 
Username=PublicKey,Role1,Role2,...
Copy to Clipboard Toggle word wrap
For example, given that your public key file, ~/.ssh/id_rsa.pub, has the following contents: 
ssh-rsa AAAAB3NzaC1kc3MAAACBAP1/U4EddRIpUt9KnC7s5Of2EbdSPO9EAMMeP4C2USZpRV1AIlH7WT2NWPq/xfW6MPbLm1Vs14E7
gB00b/JmYLdrmVClpJ+f6AR7ECLCT7up1/63xhv4O1fnfqimFQ8E+4P208UewwI1VBNaFpEy9nXzrith1yrv8iIDGZ3RSAHHAAAAFQCX
YFCPFSMLzLKSuYKi64QL8Fgc9QAAAnEA9+GghdabPd7LvKtcNrhXuXmUr7v6OuqC+VdMCz0HgmdRWVeOutRZT+ZxBxCBgLRJFnEj6Ewo
FhO3zwkyjMim4TwWeotifI0o4KOuHiuzpnWRbqN/C/ohNWLx+2J6ASQ7zKTxvqhRkImog9/hWuWfBpKLZl6Ae1UlZAFMO/7PSSoAAACB
AKKSU2PFl/qOLxIwmBZPPIcJshVe7bVUpFvyl3BbJDow8rXfskl8wO63OzP/qLmcJM0+JbcRU/53Jj7uyk31drV2qxhIOsLDC9dGCWj4
7Y7TyhPdXh/0dthTRBy6bqGtRPxGa7gJov1xm/UuYYXPIUR/3x9MAZvZ5xvE0kYXO+rx jdoe@doemachine.local
Copy to Clipboard Toggle word wrap
You can create the jdoe user with the admin role by adding the following entry to the InstallDir/etc/keys.properties file (on a single line): 
jdoe=AAAAB3NzaC1kc3MAAACBAP1/U4EddRIpUt9KnC7s5Of2EbdSPO9EAMMeP4C2USZpRV1AIlH7WT2NWPq/xfW6MPbLm1Vs14E7
gB00b/JmYLdrmVClpJ+f6AR7ECLCT7up1/63xhv4O1fnfqimFQ8E+4P208UewwI1VBNaFpEy9nXzrith1yrv8iIDGZ3RSAHHAAAAFQCX
YFCPFSMLzLKSuYKi64QL8Fgc9QAAAnEA9+GghdabPd7LvKtcNrhXuXmUr7v6OuqC+VdMCz0HgmdRWVeOutRZT+ZxBxCBgLRJFnEj6Ewo
FhO3zwkyjMim4TwWeotifI0o4KOuHiuzpnWRbqN/C/ohNWLx+2J6ASQ7zKTxvqhRkImog9/hWuWfBpKLZl6Ae1UlZAFMO/7PSSoAAACB
AKKSU2PFl/qOLxIwmBZPPIcJshVe7bVUpFvyl3BbJDow8rXfskl8wO63OzP/qLmcJM0+JbcRU/53Jj7uyk31drV2qxhIOsLDC9dGCWj4
7Y7TyhPdXh/0dthTRBy6bqGtRPxGa7gJov1xm/UuYYXPIUR/3x9MAZvZ5xvE0kYXO+rx,admin
Copy to Clipboard Toggle word wrap
Important
Do not insert the entire contents of the id_rsa.pub file here. Insert just the block of symbols which represents the public key itself.
After starting the container, you can check whether public key authentication is supported by running the jaas:realms console command, as follows: 
Index Realm                Module Class                                                                    
    1 karaf                org.apache.karaf.jaas.modules.properties.PropertiesLoginModule                  
    2 karaf                org.apache.karaf.jaas.modules.publickey.PublickeyLoginModule
Copy to Clipboard Toggle word wrap
You should see that the PublickeyLoginModule is installed. With this configuration you can log in to the container using either username/password credentials or public key credentials.
Logging in using key-based SSH
Copy link
You are now ready to login to the container using the key-based SSH utility. For example: 
$ ssh -p 8101 jdoe@localhost _ ____ ______ | | _ \ | ____| | | |_) | ___ ___ ___ | |__ _ _ ___ ___ _ | | _ < / _ \/ __/ __| | __| | | / __|/ _ \ | |__| | |_) | (_) \__ \__ \ | | | |_| \__ \ __/ \____/|____/ \___/|___/___/ |_| \__,_|___/\___| JBoss Fuse (6.0.0.redhat-xxx) http://www.redhat.com/products/jbossenterprisemiddleware/fuse/ Hit '<tab>' for a list of available commands and '[cmd] --help' for help on a specific command. Hit '<ctrl-d>' or 'osgi:shutdown' to shutdown JBoss Fuse. JBossFuse:fbolton@root>
Copy to Clipboard Toggle word wrap
Note
If you are using an encrypted private key, the ssh utility will prompt you to enter the pass phrase.

9.3. Stopping a Remote Container
Copy link

Using the stop script
Copy link

You can stop a remote container without starting up Red Hat JBoss Fuse on your local host by running the stop(.bat) script from the local InstallDir/bin directory.

Example 9.6. stop Script Syntax

stop [ -a port ] { -h hostname } { -u username } { -p password }

-a port
The SSH port of the remote instance. Defaults to 8101.
-h hostname
The hostname of the machine that the remote instance is running on.
-u username
The username used to connect to the remote instance. Use valid JAAS login credentials that have admin privileges
-p password
The password used to connect to the remote instance.

Using the remote console
Copy link

If you have connected to a remote console using the ssh:ssh command or the remote client, you can stop the remote instance using the osgi:shutdown command.
Note
Pressing Ctrl+D in a remote console simply closes the remote connection and returns you to the local shell.

Chapter 10. Managing Child Containers
Copy link

Abstract

A child container is a container that shares a common Red Hat JBoss Fuse runtime with a parent container, but has its own configuration files, runtime information, logs and temporary files. The child container functions as an independent container into which you can deploy bundles.

10.1. Standalone Child Containers
Copy link

Using the admin console commands
Copy link

The admin console commands allow you to create and manage instances of the JBoss Fuse runtime on the same machine. Each new runtime is a child instance of the runtime that created it. You can easily manage the children using names instead of network addresses. For details on the admin commands, see Admin Console Commands.

Creating child containers
Copy link

You create a new runtime container by typing admin:create in the JBoss Fuse console.
As shown in Example 10.1, “Creating a Runtime Instance”, admin:create causes the container to create a new child container in the active container's instances/containerName directory. The child container is assigned an SSH port number based on an incremental count starting at 8101. Creating a container this way does not inherit configuration information from the parent; any feature repositories and features needed from the parent will have to be manually added to the child.

Example 10.1. Creating a Runtime Instance

FuseESB@root>admin:create finn
Creating new instance on port 8106 at: /home/fuse/esb4/instances/finn Creating dir: /home/fuse/esb4/instances/finn/bin Creating dir: /home/fuse/esb4/instances/finn/etc Creating dir: /home/fuse/esb4/instances/finn/system Creating dir: /home/fuse/esb4/instances/finn/deploy Creating dir: /home/fuse/esb4/instances/finn/data Creating file: /home/fuse/esb4/instances/finn/etc/config.properties Creating file: /home/fuse/esb4/instances/finn/etc/java.util.logging.properties Creating file: /home/fuse/esb4/instances/finn/etc/org.apache.felix.fileinstall-deploy.cfg Creating file: /home/fuse/esb4/instances/finn/etc/org.apache.karaf.log.cfg Creating file: /home/fuse/esb4/instances/finn/etc/org.apache.karaf.features.cfg Creating file: /home/fuse/esb4/instances/finn/etc/org.apache.karaf.management.cfg Creating file: /home/fuse/esb4/instances/finn/etc/org.ops4j.pax.logging.cfg Creating file: /home/fuse/esb4/instances/finn/etc/org.ops4j.pax.url.mvn.cfg Creating file: /home/fuse/esb4/instances/finn/etc/startup.properties Creating file: /home/fuse/esb4/instances/finn/etc/system.properties Creating file: /home/fuse/esb4/instances/finn/etc/org.apache.karaf.shell.cfg Creating file: /home/fuse/esb4/instances/finn/bin/karaf Creating file: /home/fuse/esb4/instances/finn/bin/start Creating file: /home/fuse/esb4/instances/finn/bin/stop
Copy to Clipboard Toggle word wrap

Cloning a container
Copy link

To create a new container which is a direct copy of its parent, use the admin:clone command. The only difference between parent and child is the port number they listen on.

Changing a child's SSH port
Copy link

You can change the SSH port number assigned to a child container using the admin:change-port command. The syntax for the command is:

admin:change-port { containerName } { portNumber }

Important
You can only use the admin:change-port command on stopped containers.

Starting child containers
Copy link

New containers are created in the stopped state. To start a child container and make it ready to host applications, use the admin:start command. This command takes a single argument, containerName, that identifies the child you want started.

Listing all child containers
Copy link

To see a list of all the JBoss Fuse containers running under a particular installation, use the admin:list command:

Example 10.2. Listing Instances

JBossFuse:karaf@root>admin:list
  Port State Pid Name [ 8107] [Started ] [10628] harry [ 8101] [Started ] [20076] root [ 8106] [Started ] [15924] dick [ 8105] [Started ] [18224] tom
Copy to Clipboard Toggle word wrap

Connecting to a child container
Copy link

You can connect to a started child container's remote console using the admin:connect command.As shown in Example 10.3, “Admin connect Command”, this command takes three arguments:

Example 10.3. Admin connect Command

admin:connect { containerName } { -u username } { -p password }

containerName
The name of the child to which you want to connect.
-u username
The username used to connect to the child's remote console. Use valid JAAS user credentials that have admin privileges (see Chapter 15, Configuring JAAS Security).
-p password
This argument specifies the password used to connect to the child's remote console.
Once you are connected to the child container., the prompt changes to display the name of the current instance, as shown: 
JBossFuse:karaf@harry>
Copy to Clipboard Toggle word wrap

Stopping a child container
Copy link

To stop a child container, from within the container itself, type osgi:shutdown or simply shutdown.
To stop a child container remotely—in other words, from a parent or sibling instance—type admin:stop containerName.

Destroying a child container
Copy link

You can permanently delete a stopped child container using the admin:destroy containerName command.
Important
You can only remove stopped children.

Changing the JVM options on a child container
Copy link

To change the Java options in a child instance, use the admin:change-opts command. For example, you could change the amamount of memory allocated to the child container's JVM, as follows: 
JBossFuse:karaf@harry> admin:change-opts tom "-server -Xms128M -Xmx1345m -Dcom.sun.management.jmxremote"
Copy to Clipboard Toggle word wrap
These changes will take effect when you restart the child container.

Using the admin script
Copy link

You can also use manage a JBoss Fuse container running in server mode without starting a new instance of the runtime. The admin script in the InstallDir/bin directory provides the all of the admin console commands except for admin:connect.

Example 10.4. The admin Script

admin.bat: Ignoring predefined value for KARAF_HOME Available commands: change-port - Changes the port of an existing container instance. create - Creates a new container instance. destroy - Destroys an existing container instance. list - List all existing container instances. start - Starts an existing container instance. stop - Stops an existing container instance. Type 'command --help' for more help on the specified command.
Copy to Clipboard Toggle word wrap
For example, to list all of the JBoss Fuse containers on your host machine, type:
Windows 
admin.bat list
Copy to Clipboard Toggle word wrap
*NIX 
./admin list
Copy to Clipboard Toggle word wrap

10.2. Fabric Child Containers
Copy link

Creating child containers
Copy link

You create a new child container using the fabric:container-create-child console command, which has the following syntax: 
karaf@root> fabric:container-create-child parent child [number]
Copy to Clipboard Toggle word wrap
Where parent is the name of an existing container in the fabric and child is the name of the new child container. If you create multiple child containers (by specifying the optional number argument), the new child instances are named child1, child2, and so on.
For example, assuming the container, root, already belongs to your fabric, you can create two new child containers as follows: 
karaf@root> fabric:container-create-child root child 2
The following containers have been created successfully:
	child1
	child2
Copy to Clipboard Toggle word wrap

Listing all container instances
Copy link

To list all of the containers in the current fabric (including child instances), use the fabric:container-list console command. For example: 
JBossFuse:karaf@root> fabric:container-list
[id]                           [version] [alive] [profiles]                     [provision status]
root                           1.0       true    fabric, fabric-ensemble-0000-1 
  child1                       1.0       true    default                        success
  child2                       1.0       true    default                        success
Copy to Clipboard Toggle word wrap

Assigning a profile to a child container
Copy link

By default, a child is assigned the default profile when it is created. To assign a new profile (or profiles) to a child container after it has been created, use the fabric:container-change-profile console command.
Note
You can assign a profile other than default to a newly created container by using the fabric:container-create-child command's --profile argument.
For example, to assign the example-camel profile to the child1 container, enter the following console command: 
JBossFuse:karaf@root> fabric:container-change-profile child1 example-camel
Copy to Clipboard Toggle word wrap
The command removes the profiles currently assigned to child1 and replaces them with the specified list of profiles (where in this case, there is just one profile in the list, example-camel).

Connecting to a child container
Copy link

To connect to a child container, use the fabric:container-connect console command. For example, to connect to child1, enter the following console command: 
JBossFuse:karaf@root>fabric:container-connect -u admin -p admin child1
Copy to Clipboard Toggle word wrap
You should see output like the following in your console window: 
Connecting to host YourHost on port 8102
Connected
      _ ____                  ______
     | |  _ \                |  ____|             
     | | |_) | ___  ___ ___  | |__ _   _ ___  ___
 _   | |  _ < / _ \/ __/ __| |  __| | | / __|/ _ \
| |__| | |_) | (_) \__ \__ \ | |  | |_| \__ \  __/
 \____/|____/ \___/|___/___/ |_|   \__,_|___/\___|

  JBoss Fuse (6.0.0.redhat-xxx)
  http://www.redhat.com/products/jbossenterprisemiddleware/fuse/

Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or 'osgi:shutdown' to shutdown JBoss Fuse.

JBossFuse:admin@child1>
Copy to Clipboard Toggle word wrap
To terminate the session, enter Ctrl-D.

Starting a child container
Copy link

To start a child container that was previously stopped, use the fabric:container-start command, providing the child container's name as the command argument—for example, to restart child1: 
JBossFuse:karaf@root>fabric:container-start child1
Copy to Clipboard Toggle word wrap
This command starts up the child in a separate JVM.

Stopping a child container
Copy link

To stop a child instance, use the fabric:container-stop command, providing the child container's name as the command argument—for example, to stop child1: 
JBossFuse:karaf@root>fabric:container-stop child1
Copy to Clipboard Toggle word wrap
This command kills the JVM process that hosts the child1 container.

Destroying a child container
Copy link

To completely destroy a child container use the fabric:container-delete command. For example, to destroy the child1 container instance, enter the following console command: 
JBossFuse:karaf@root> fabric:container-delete child1
Copy to Clipboard Toggle word wrap
Destroying a child container does the following:
  • stops the child's JVM process
  • physically removes all files related to the child container

Chapter 11. Deploying a New Broker Instance
Copy link

Abstract

Red Hat JBoss Fuse supports the deployment of multiple JMS brokers in a container. Doing so involves creating a new set of broker configurations and deploying them to the container.

Overview
Copy link

Deploying a new broker instance involves creating a new OSGi broker configuration and deploying it into the container. In a standalone container this can be done from the command console using the config command shell. For containers deployed in a fabric, you need to either create a profile for the new broker, or modify an existing profile to include the new broker configuration.
You will also likely want to create a new Apache ActiveMQ template configuration file that allows you to modify the desired settings. This will involve creating a new Apache ActiveMQ XML file and making it accessible to container.

Standalone containers
Copy link

To deploy a new broker into a standalone container:
  1. Create a template Apache ActiveMQ XML configuration file in a location that is accessible to the container.
  2. In the JBoss Fuse command console, use the config:edit command to create a new OSGi configuration file.
    Important
    The PID must start with org.fusesource.mq.fabric.server-.
  3. Use the config:propset command to associate your template XML configuration with the broker OSGi configuration as shown in Example 11.1, “Specifying a Broker's Template XML Configuration”.

    Example 11.1. Specifying a Broker's Template XML Configuration

    JBossFuse:karaf@root> config:propset config configFile
    Copy to Clipboard Toggle word wrap
  4. Use the config:propset command to set the required properties.
    The properties that need to be set will depend on the properties you specified using property place holders in the template XML configuration and the broker's network settings.
    For information on using config:propset see section "Details" in "Console Reference".
  5. Save the new OSGi configuration using the config:update command.
Once the new OSGi configuration is saved the new broker instance will start.
Note
If you want to simply deploy a second broker that uses the default configuration template skip Step 1. You will need set the config property to ${karaf.base}/etc/activemq.xml. You will also need to provide values for the data property, the broker-name property, and the openwire-port property.

Fabric containers
Copy link

To deploy a new broker into a container in a fabric:
  1. Create a template Apache ActiveMQ XML configuration file in a location that is accessible to the container.
  2. In the JBoss Fuse command console, use the fabric:import command to upload the your XML configuration template to the Fabric Ensemble as shown in Example 11.2, “Uploading a Template to a Fabric Ensemble”.

    Example 11.2. Uploading a Template to a Fabric Ensemble

    JBossFuse:karaf@root> fabric:import -t /fabric/configs/versions/version/profiles/mq-base/configFile configFile
    Copy to Clipboard Toggle word wrap
    version must match the version of the new profile you will create for the new broker.
  3. Use the fabric:mq-create command to create a profile for the new broker and assign it to a container.
    • To deploy the new broker into an existing container use the command shown in Example 11.3, “Creating a New Broker in an Existing Container”

      Example 11.3. Creating a New Broker in an Existing Container

      JBossFuse:karaf@root> fabric:mq-create --assign-container containerName --config configFile profileName
      Copy to Clipboard Toggle word wrap
      This will create a new broker profile that inherits from the mq-base profile, but uses your XML configuration template, and deploy it to the specified container.
    • To deploy the new broker into an new container use the command shown in Example 11.4, “Creating a New Broker in a New Container”

      Example 11.4. Creating a New Broker in a New Container

      JBossFuse:karaf@root> fabric:mq-create --create-container containerName --config configFile profileName
      Copy to Clipboard Toggle word wrap
      This will create a new broker profile that inherits from the mq-base profile, but uses your XML configuration template, create a new container named containerName, and deploy the broker profile to it.
      Note
      The new container will be a child of the container from which you execute the fabric:mq-create command.
    Note
    You can add network configuration settings to the profile as well. See section "Arguments" in "Console Reference".
  4. Use the fabric:profile-edit command shown in Example 11.5, “Editing a Broker Profile” to set the required properties.

    Example 11.5. Editing a Broker Profile

    JBossFuse:karaf@root> fabric:profile-edit --pid org.fusesource.mq.fabric.server-profileName/property=value profileName
    Copy to Clipboard Toggle word wrap
    The properties that need to be set will depend on the properties you specified using property place holders in the template XML configuration and the broker's network settings.
    For information on using fabric:profile-edit see section "Description" in "Console Reference".
Note
If you want to simply deploy a second broker that uses the default configuration template skip Step 1 and Step 2.
Note
The management console makes this process easier by providing a Web based UI.

Example
Copy link

If you wanted to deploy a new instance of the default broker called myBroker that stores its data in InstallDir/data/myBroker and opens a port at 61617, you would do the following:
  1. Open the JBoss Fuse command console.
  2. In the JBoss Fuse command console, use the config:edit command to create a new OSGi configuration file: 
    JBossFuse:karaf@root> config:edit org.fusesource.mq.fabric.server-myBroker
    Copy to Clipboard Toggle word wrap
  3. Use the config:propset command to associate your template XML configuration with the broker OSGi configuration: 
    JBossFuse:karaf@root> config:propset config ${karaf.base}/etc/activemq.xml
    Copy to Clipboard Toggle word wrap
  4. Use the config:propset command to specify the new broker's data directory: 
    JBossFuse:karaf@root> config:propset data ${karaf.data}/myBroker
    Copy to Clipboard Toggle word wrap
  5. Use the config:propset command to specify the new broker's name: 
    JBossFuse:karaf@root> config:propset broker-name myBroker
    Copy to Clipboard Toggle word wrap
  6. Use the config:propset command to specify the new broker's openwire port: 
    JBossFuse:karaf@root> config:propset openwire-port 61617
    Copy to Clipboard Toggle word wrap
  7. Save the new OSGi configuration using the config:update command.

Chapter 12. Configuring Red Hat JBoss Fuse
Copy link

Revision History
08/20/12
Making the chapter a more generic description of the configuration mechanism and adding information about manipulating the configuration with Fuse Fabric

Abstract

Red Hat JBoss Fuse uses the OSGi Configuration Admin service to manage the configuration of OSGi services. How you feed information to the configuration service depends on how the container is deployed.

12.1. Introducing Red Hat JBoss Fuse Configuration
Copy link

OSGi configuration
Copy link

The OSGi Configuration Admin service specifies the configuration information for deployed services and ensures that the services receive that data when they are active.
A configuration is a list of name-value pairs read from a .cfg file in the InstallDir/etc directory. The file is interpreted using the Java properties file format. The filename is mapped to the persistent identifier (PID) of the service that is to be configured. In OSGi, a PID is used to identify a service across restarts of the container.

Configuration files
Copy link

You can configure the Red Hat JBoss Fuse runtime using the following files:
Expand
Table 12.1. Red Hat JBoss Fuse Configuration Files
FilenameDescription
activemq.xmlConfigures the default Apache ActiveMQ broker in a Fabric (used in combination with the org.fusesource.mq.fabric.server-default.cfg file).
config.propertiesThe main configuration file for the container See Section 12.2, “Setting OSGi Framework and Initial Container Properties” for details.
keys.propertiesLists the users who can access the JBoss Fuse runtime using the SSH key-based protocol. The file's contents take the format username=publicKey,role
org.apache.aries.transaction.cfgConfigures the transaction feature
org.apache.felix.fileinstall-deploy.cfgConfigures a watched directory and polling interval for hot deployment.
org.apache.karaf.features.cfgConfigures a list of feature repositories to be registered and a list of features to be installed when JBoss Fuse starts up for the first time.
org.apache.karaf.features.obr.cfgConfigures the default values for the features OSGi Bundle Resolver (OBR).
org.apache.karaf.jaas.cfgConfigures options for the Karaf JAAS login module. Mainly used for configuring encrypted passwords (disabled by default).
org.apache.karaf.log.cfgConfigures the output of the log console commands. See Section 17.1, “Logging Configuration”.
org.apache.karaf.management.cfg
Configures the JMX system. See Chapter 14, Configuring JMX for details.
org.apache.karaf.shell.cfg
Configures the properties of remote consoles. For more information see Section 9.1, “Configuring a Container for Remote Access”.
org.apache.servicemix.jbi.cfg
Configures the shutdown timeout for the JBI container.
org.apache.servicemix.nmr.cfg
Configures the default thread pool settings for JBI. See .
org.apache.servicemix.components.Name.cfg
Configures the thread pool settings specifically for the Name JBI component. See .
org.fusesource.bai.agent.cfgConfigures the Fuse BAI (Business Activity Insight) feature, if it is installed.
org.fusesource.fabric.fab.osgi.url.cfgConfigures the Maven repositories used by the Fuse Application Bundle (FAB) runtime when downloading artifacts. If the properties in this file are not set, FAB defaults to the values in org.ops4j.pax.url.mvn.cfg.
org.fusesource.fabric.maven.cfgConfigures the Maven repositories used by the Fabric Maven Proxy when downloading artifacts, (The Fabric Maven Proxy is used for provisioning new containers on a remote host.)
org.fusesource.mq.fabric.server-default.cfgConfigures the default Apache ActiveMQ broker in a Fabric (used in combination with the activemq.xml file).
org.jclouds.shell.cfgConfigures options for formatting the output of jclouds:* console commands.
org.ops4j.pax.logging.cfg
Configures the logging system. For more, see Section 17.1, “Logging Configuration”.
org.ops4j.pax.url.mvn.cfgConfigures additional URL resolvers.
org.ops4j.pax.web.cfgConfigures the default Jetty container (Web server). See Securing the Web Console.
startup.properties
Specifies which bundles are started in the container and their start-levels. Entries take the format bundle=start-level.
system.properties
Specifies Java system properties. Any properties set in this file are available at runtime using System.getProperties(). See Setting System and Config Properties for more.
users.propertiesLists the users who can access the JBoss Fuse runtime either remotely or via the web console. The file's contents take the format username=password,role

Configuration file naming convention
Copy link

The file naming convention for configuration files depends on whether the configuration is intended for an OSGi Managed Service or for an OSGi Managed Service factory.
The configuration file for an OSGi Managed Service obeys the following naming convention: 
<PID>.cfg
Copy to Clipboard Toggle word wrap
Where <PID> is the persistent ID of the OSGi Managed Service (as defined in the OSGi Configuration Admin specification). A persistent ID is normally dot-delimited—for example, org.ops4j.pax.web.
The configuration file for an OSGi Managed Service Factory obeys the following naming convention: 
<PID>-<InstanceID>.cfg
Copy to Clipboard Toggle word wrap
Where <PID> is the persistent ID of the OSGi Managed Service Factory. In the case of a managed service factory's <PID>, you can append a hyphen followed by an arbitrary instance ID, <InstanceID>. The managed service factory then creates a unique service instance for each <InstanceID> that it finds.

JBI component configuration
Copy link

In addition to the container's configuration files, the InstallDir/etc folder may contain a number of configuration files for the JBI components that ship with Red Hat JBoss Fuse.
The component configuration files are named using the scheme org.apache.servicemix.components.ComponentName.cfg. For example, you would configure the JMS component using a file called org.apache.servicemix.components.jms.cfg.
The contents of a component's configuration file is largely component specific. However, each component configuration file contains properties for configuring the thread pool used by the component to process message exchanges. See Chapter 20, Configuring JBI Component Thread Pools for details.
Revision History
09/11/2012
Added overview and clarified what these properties are used for

Overview
Copy link

There are a number of configuration properties that are set when a container is bootstrapped. These properties include the container's name, the default features repository used by the container, the OSGi framework provider, and other settings. These properties are specified in two property files in the etc folder:
  • config.properties—specifies the bootstrap properties for the OSGi framework
  • system.properties—specifies properties to configure container functions

OSGi framework properties
Copy link

The etc/config.properties file contains the properties used to specify which OSGi framework implementation to load and properties for configuring the framework's behaviors. Table 12.2, “Properties for the OSGi Framework” describes the key properties to set.
Expand
Table 12.2. Properties for the OSGi Framework
PropertyDescription
karaf.frameworkSpecifies the OSGi framework that Red Hat JBoss Fuse uses. The default framework is Apache Felix which is specified using the value felix.
karaf.framework.felixSpecifies the path to the Apache Felix JAR on the file system.
Important
JBoss Fuse only supports the Apache Felix OSGi implementation.

Initial container properties
Copy link

The etc/system.properties file contains properties that configure how various aspects of the container behave including:
  • the container's name
  • the default feature repository used by the container
  • the default port used by the OSGi HTTP service
  • the initial message broker configuration
Table 12.3, “Container Properties” describes some of the common properties.
Expand
Table 12.3. Container Properties
PropertyDescription
karaf.nameSpecifies the name of this container. The default is root.
karaf.default.repositorySpecifies the location of the feature repository the container will use by default. The default setting is the local feature repository installed with JBoss Fuse.
org.osgi.service.http.portSpecifies the default port for the OSGi HTTP Service.
Revision History
09/11/2012
Clarified the focus that this content was only for non-fabric containers

Overview
Copy link

The command console's config shell provides commands for editing the configuration of a standalone container. The commands allow you to inspect the container's configuration, add new PIDs, and edit the properties of any PID used by the container. These configuration changes are applied directly to the container and will persist across container restarts.
For more details on the config commands see chapter "Config Console Commands" in "Console Reference".

Listing the current configuration
Copy link

The config:list command will show all of the PIDs currently in use by the container. As shown in Example 12.1, “Output of the config:list Command”, the output from config:list contains all of the PIDs and all of the properties for each of the PIDs.

Example 12.1. Output of the config:list Command

...
---------------------------------------------------------------- Pid: org.ops4j.pax.logging BundleLocation: mvn:org.ops4j.pax.logging/pax-logging-service/1.4 Properties: log4j.appender.out.layout.ConversionPattern = %d{ABSOLUTE} | %-5.5p | %-16.16 t | %-32.32c{1} | %-32.32C %4L | %m%n felix.fileinstall.filename = org.ops4j.pax.logging.cfg service.pid = org.ops4j.pax.logging log4j.appender.stdout.layout.ConversionPattern = %d{ABSOLUTE} | %-5.5p | %-16 .16t | %-32.32c{1} | %-32.32C %4L | %m%n log4j.appender.out.layout = org.apache.log4j.PatternLayout log4j.rootLogger = INFO, out, osgi:VmLogAppender log4j.appender.stdout.layout = org.apache.log4j.PatternLayout log4j.appender.out.file = C:\apache\apache-servicemix-6.0.0.redhat-024/data/log/karaf.log log4j.appender.stdout = org.apache.log4j.ConsoleAppender log4j.appender.out.append = true log4j.appender.out = org.apache.log4j.FileAppender ---------------------------------------------------------------- Pid: org.ops4j.pax.web BundleLocation: mvn:org.ops4j.pax.web/pax-web-runtime/0.7.1 Properties: org.apache.karaf.features.configKey = org.ops4j.pax.web service.pid = org.ops4j.pax.web org.osgi.service.http.port = 8181 ----------------------------------------------------------------
...
Copy to Clipboard Toggle word wrap
Listing the container's configuration is a good idea before editing a container's configuration. You can use the output to ensure that you know the exact PID to change.

Editing the configuration
Copy link

Editing a container's configuration involves a number of commands and must be done in the proper sequence. Not following the proper sequence can lead to corrupt configurations or the loss of changes.
To edit a container's configuration:
  1. Start an editing session by typing config:edit PID.
    PID is the PID for the configuration you are editing. It must be entered exactly. If it does not match the desired PID, the container will create a new PID with the specified name.
  2. Remind yourself of the available properties in a particular configuration by typing config:proplist.
  3. Use one of the editing commands to change the properties in the configuration.
    The editing commands include:
    • config:propappend—appends a new property to the configuration
    • config:propset—set the value for a configuration property
    • config:propdel—delete a property from the configuration
  4. Update the configuration in memory and save it to disk by typing config:update.
Note
To exit the configuration, without saving your changes, type config:cancel.
Example 12.2, “Editing a Configuration” shows a configuration editing session that changes a container's logging behavior.

Example 12.2. Editing a Configuration

JBossFuse:karaf@root> config:edit org.apache.karaf.log
JBossFuse:karaf@root> config:proplist
 service.pid = org.apache.karaf.log size = 500 felix.fileinstall.filename = org.apache.karaf.log.cfg pattern = %d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
JBossFuse:karaf@root> config:propset size 300
JBossFuse:karaf@root> config:update
Copy to Clipboard Toggle word wrap

12.4. Configuring Fabric Containers
Copy link

Overview
Copy link

When a container is part of a fabric, it does not manage its configuration. The container's configuration is managed by the Fabric Agent. The agent runs along with the container and updates the container's configuration based on information from the fabric's registry.
Because the configuration is managed by the Fabric Agent, any changes to the container's configuration needs to be done by updating the fabric's registry. In a fabric, container configuration is determined by one or more profiles that are deployed into the container. To change a container's configuration, you must update the profile(s) deployed into the container using either the console's fabric: shell or the management console.

Profiles
Copy link

All configuration in a fabric is stored as profiles in the Fabric Registry. One or more profiles are assigned to containers that are part of the fabric. A profile is a collection of configuration that specifies:
  • the Apache Karaf features to be deployed
  • OSGi bundles to be deployed
  • the feature repositories to be scanned for features
  • properties that configure the container's runtime behavior
The configuration profiles are collected into versions. Versions are typically used to make updates to an existing profile without effecting deployed containers. When a container is configured it is assigned a profile version from which it draws the profiles. Therefore, when you create a new version and edit the profiles in the new version, the profiles that are in use are not changed. When you are ready to test the changes, you can roll them out incrementally by moving containers to a new version one at a time.
When a container joins a fabric, a Fabric Agent is deployed with the container and takes control of the container's configuration. The agent will ask the Fabric Registry what version and profile(s) are assigned to the container and configure the container based on the profiles. The agent will download and install of the specified bundles and features. It will also set all of the specified configuration properties.

Best practices
Copy link

Editing a profile makes changes to the copy in the Fabric Registry and all of the Fabric Agents are alerted when changes are made. If a running container is using a profile that is changed, its agent will automatically apply the new settings. If the update is benign having the change rolled out to the entire fabric is not an issue. If, on the other hand, the change causes issues, the entire fabric could become unstable.
To avoid having untested changes infecting an entire fabric, you should always make a new version before editing a profile. This isolates the changes in a version that is not running on any containers and provides a quick backup in case the changes are bad.
Once the profile changes have been made, you should test them out by upgrading only a few containers to the new version to see how they behave. As you become confident that the changes are good, you can then upgrade more containers.

Making changes using the command console
Copy link

The command console's fabric shell has commands for managing profiles and versions in a fabric. These commands include:
  • fabric:version-create—create a new version
  • fabric:profile-create—create a new profile
  • fabric:profile-edit—edit the properties in a profile
  • fabric:container-change-profile—change the profiles assigned to a container
Example 12.3, “Editing Fabric Profile” shows a session for updating a profile using the command console.

Example 12.3. Editing Fabric Profile

JBossFuse:karaf@root> fabric:version-create
Created version: 1.1 as copy of: 1.0
JBossFuse:karaf@root> fabric:profile-edit -p org.apache.karaf.log/size=300 NEBroker
Copy to Clipboard Toggle word wrap
The change made in Example 12.3, “Editing Fabric Profile” is not applied to any running containers because it is made in a new version. In order to apply the change you need to update one or more containers using the fabric:container-upgrade command.
See chapter "Fabric Console Commands" in "Console Reference" for more information.

Using the management console
Copy link

The management console simplifies the process of configuring containers in a fabric by providing an easy to use Web-based interface and reducing the number of steps required to make the changes. For more information on using the management console see Using the Management Console.

Chapter 13. Configuring the Hot Deployment System
Copy link

Abstract

Standalone containers scan a directory for OSGi bundles and JBI artifacts to automatically load. You can change the location of this folder and the interval at which the folder is scanned.

Overview
Copy link

Standalone containers will automatically load and deploy OSGi bundles and JBI artifacts from a pre-configured folder. It scans the folder once a second for new bundles or JBI artifacts. You can change the folder a container scans and the scan interval by editing properties in the org.apache.felix.fileinstall-deploy PID.

Specifying the hot deployment folder
Copy link

By default, a container scans the deploy folder that is relative to the folder from which you launched the container. You change the folder the container monitors by setting the felix.fileinstall.dir property in the rg.apache.felix.fileinstall-deploy PID. The value is the absolute path of the folder to monitor. If you set the value to /home/joe/deploy, the container will monitor a folder in Joe's home directory.

Specifying the scan interval
Copy link

By default containers scan the hot deployment folder every 1000 milliseconds. To change the interval between scans of the hot deployment folders, you change the felix.fileinstall.poll property in the org.apache.felix.fileinstall-deploy PID. The value is specified in milliseconds.

Example
Copy link

Example 13.1, “Configuring the Hot Deployment Folders” shows a configuration editing session that sets /home/smx/jbideploy as the hot deployment folder and sets the scan interval to half a second.

Example 13.1. Configuring the Hot Deployment Folders

JBossFuse:karaf@root> config:edit org.apache.felix.fileinstall-deploy
JBossFuse:karaf@root> config:propset felix.fileinstall.dir /home/smx/jbideploy
JBossFuse:karaf@root> config:propset felix.fileinstall.poll 500
JBossFuse:karaf@root> config:update
Copy to Clipboard Toggle word wrap

Chapter 14. Configuring JMX
Copy link

Abstract

Red Hat JBoss Fuse uses JMX for its underlying management features. You can configure the JMX RMI port, the JMX URL, and the credentials used to access the JMX features.

Overview
Copy link

Red Hat JBoss Fuse uses JMX for reporting runtime metrics and providing some limited management capabilities. You can configure how the JMX management features are accessed by changing the properties in the org.apache.karaf.management PID.

Changing the RMI port and JMX URL
Copy link

Two of the most commonly changed parts of a container's JMX configuration are the RMI port and the JMX URL. You can set these using the properties described in Table 14.1, “JMX Access Properties”.
Expand
Table 14.1. JMX Access Properties
PropertyDescription
rmiRegistryPortSpecifies the RMI registry port. The default value is 1099.
serviceUrlSpecifies the the URL used to connect to the JMX server. The default URL is service:jmx:rmi:///jndi/rmi://localhost:1099/karaf-KarafName, where KarafName is the container's name (by default, root).

Setting the JMX username and password
Copy link

In a standalone container, use any valid JAAS user credentials (see the section called “Create a secure JAAS user”).
In a fabric, the default username is admin and the default password is admin.
You can change the username and password used to connect to the JMX server by configuring the JAAS security system as described in Chapter 15, Configuring JAAS Security.

Troubleshooting on Linux platforms
Copy link

On Linux platforms, if you have trouble getting a remote JConsole instance to connect to the JMX server, check the following points:
  • Check that the hostname resolves to the correct IP address. For example, if the hostname -i command returns 127.0.0.1, JConsole will not be able to connect to the JMX server. To fix this, edit the /etc/hosts file so that the hostname resolves to the correct IP address.
  • Check whether the Linux machine is configured to accept packets from the host where JConsole is running (packet filtering is built in the Linux kernel). You can enter the command, /sbin/iptables --list, to determine whether an external client is allowed to connect to the JMX server.
    Use the following command to add a rule to allow an external client such as JConsole to connect: 
    /usr/sbin/iptables -I INPUT -s JconsoleHost -p tcp --destination-port JMXRemotePort -j ACCEPT
    Copy to Clipboard Toggle word wrap
    Where JconsoleHost is either the hostname or the IP address of the host on which JConsole is running and JMXRemotePort is the IP port exposed by the JMX server.

Chapter 15. Configuring JAAS Security
Copy link

15.1. Alternative JAAS Realms
Copy link

Overview
Copy link

The Java Authentication and Authorization Service (JAAS) is a pluggable authentication service, which is implemented by a login module. A particular instance of a JAAS service is known as a JAAS realm and is identified by a realm name.
Applications integrated with JAAS must be configured to use a specific realm, by specifying the realm name.

Default realm
Copy link

The default realm in Red Hat JBoss Fuse is identified by the karaf realm name. The standard administration services in JBoss Fuse (SSH remote console, JMX port, and so on) are all configured to use the karaf realm by default.

Available realm implementations
Copy link

JBoss Fuse provides the following alternative JAAS realm implementations:

Standalone JAAS realm
Copy link

In a standalone container, the karaf realm installs two JAAS login modules, which are used in parallel:
PropertiesLoginModule
Authenticates username/password credentials and stores the secure user data in the InstallDir/etc/users.properties file.
PublickeyLoginModule
Authenticates SSH key-based credentials (consisting of a username and a public/private key pair). Secure user data is stored in the InstallDir/etc/keys.properties file.

Fabric JAAS realm
Copy link

In a fabric, a karaf realm based on the ZookeeperLoginModule login module is automatically installed in every container (the fabric-jaas feature is included in the default profile) and is responsible for securing the SSH remote console and other administrative services. The Zookeeper login module stores the secure user data in the Fabric Registry.
Note
In containers where the standalone JAAS realm and the Fabric JAAS realm are both installed, the Fabric JAAS realm takes precedence, because it defines a karaf realm with a higher rank.

LDAP JAAS realm
Copy link

It is also possible to configure a container to use an LDAP login module with JAAS. For details of how to set this up, see LDAP Authentication Tutorial.

15.2. JAAS Console Commands
Copy link

Editing user data from the console
Copy link

Red Hat JBoss Fuse provides a set of jaas:* console commands, which you can use to edit JAAS user data from the console.
Note
The jaas:* console commands are not compatible with the LDAP JAAS module.

Standalone realm configuration
Copy link

A standalone container (which uses the JAAS PropertiesLoginModule and the PublickeyLoginModule) maintains its own database of secure user data, independently of any other containers. To configure the user data for a standalone container, you must log into the specific container (see Connecting and Disconnecting Remotely) whose data you want to modify. Each standalone container must be configured separately.
To start editing the standalone JAAS user data, you must first specify the JAAS realm that you want to modify. To see the available realms, enter the jaas:realms command, as follows: 
JBossFuse:karaf@root> jaas:realms
Index Realm                Module Class                                                                    
    1 karaf                org.apache.karaf.jaas.modules.properties.PropertiesLoginModule                  
    2 karaf                org.apache.karaf.jaas.modules.publickey.PublickeyLoginModule
Copy to Clipboard Toggle word wrap
Both of these login modules are active in the default karaf JAAS realm. Enter the following console command to start editing the properties login module in the karaf realm: 
JBossFuse:karaf@root> jaas:manage --index 1
Copy to Clipboard Toggle word wrap

Adding a new user to the JAAS realm
Copy link

For example, consider how to add a new user, jdoe, to the JAAS realm.
First of all, start to manage the relevant JAAS realm as follows:
  1. List the available realms and login modules by entering the following command: 
    JBossFuse:karaf@root> jaas:realms
    Copy to Clipboard Toggle word wrap
  2. Choose the login module to edit by specifying its index, Index, using a command of the following form: 
    JBossFuse:karaf@root> jaas:manage --index Index
    Copy to Clipboard Toggle word wrap
Add the user, jdoe, with password, secret, by entering the following console command: 
JBossFuse:karaf@root> jaas:useradd jdoe secret
Copy to Clipboard Toggle word wrap
Add the admin role to jdoe, by entering the following console command: 
JBossFuse:karaf@root> jaas:roleadd jdoe admin
Copy to Clipboard Toggle word wrap
As a matter of fact, these changes are not applied right away. Initially, the changes are queued in a list of pending operations. To see this list, enter the jaas:pending console command, as follows: 
JBossFuse:karaf@root> jaas:pending
Jaas Realm:karaf Jaas Module:org.apache.karaf.jaas.modules.properties.PropertiesLoginModule
UserAddCommand{username='jdoe', password='secret'}
RoleAddCommand{username='jdoe', role='admin'}
Copy to Clipboard Toggle word wrap
Now you can apply the changes by invoking jaas:update, as follows: 
JBossFuse:karaf@root> jaas:update
Copy to Clipboard Toggle word wrap
The new user entry is then persisted (either by writing to the remote container's etc/users.properties file, in the case of a standalone container, or by storing the user data in the Fabric Registry, in the case of a fabric).

Canceling pending changes
Copy link

If you decide that you do not want to make the changes permanent after all, instead of invoking the jaas:update command, you could abort the pending changes using the jaas:cancel command, as follows: 
JBossFuse:karaf@root> jaas:cancel
Copy to Clipboard Toggle word wrap

15.3. Standalone Realm Properties File
Copy link

Overview
Copy link

The default JAAS realm used by a standalone container is implemented by the PropertiesLoginModule JAAS module. This login module stores its user data in a Java properties file in the following location: 
InstallDir/etc/users.properties
Copy to Clipboard Toggle word wrap

Format of users.properties entries
Copy link

Each entry in the etc/users.properties file has the following format (on its own line): 
Username=Password,Role1,Role2,...
Copy to Clipboard Toggle word wrap

Changing the default username and password
Copy link

The etc/users.properties file initially contains a commented out entry for a single user, smx, with password smx and role admin. It is strongly recommended that you create a new user entry that is different from the smx user example.
For example, you could create a new user in the following format: 
Username=Password,admin
Copy to Clipboard Toggle word wrap
Where the admin role grants full administration privileges to this user.

Chapter 16. Securing Fabric Containers
Copy link

Abstract

By default, fabric containers uses text-based username/password authentication. Setting up a more robust access control system involves creating and deploying a new JAAS realm to the containers in the fabric.
The default fabric authentication mechanism uses a text-based authentication cache that is stored on the fabric's registry. This authentication mechanism is used to control who can access fabric containers, who can issue commands to remote containers, who can update fabric profiles, and who can retrieve the details on the container's in the fabric. The management console also uses the fabric's authentication scheme.
The authentication system uses the JAAS framework. The fabric uses the karaf JAAS realm. This realm is defined in the fabric-jaas feature. It is deployed to all containers in the fabric as part of the default profile.
Important
The default authentication system is not recommended for production use.
You can configure the fabric to use a different authentication mechanism by overriding the karaf JAAS realm to use a proper login module. The fabric containers include an LDAP module that is preloaded and simply needs to be activated. Doing so requires that the new JAAS realm be defined in OSGi blueprint files and deployed to the container's in the fabric.

16.1. Using the Default Authentication System
Copy link

Revision History
12/3/12
clarified that the default mechanism is the one used by the fabric
12/3/12
split into sub-sections for user management and configuring encryption

Abstract

The default authentication system for the fabric can be managed using management console's Users. It can also be enhanced to store passwords using encryption.
By default fabric uses a simple text-based authentication system. This system allows you to define user accounts and assign passwords and roles to the users. Out of the box, the user credentials are stored in the fabric registry unencrypted.
You can mange the users in the default realm using the Users tab. You can also strengthen the default system by configuring it to use encryption when storing user credentials.

16.1.1. Managing Users
Copy link

Viewing user data
Copy link
To view the users configured to access fabric select the Users item from the main menu. This will open the Users page.
The Users page lists all of the users along the left hand side of the page. If you select the user, the user's roles will be displayed along the right hand of the page and you the buttons to edit the user will become active.
Adding a user
Copy link
To add a user:
  1. Click Users from the main menu.
    The Users page opens.
  2. Click Create User.
    The Create New User dialog opens.
  3. In the Username field, enter a unique name for the user.
    The user name must be at least five characters long.
  4. In the Password field, enter a password for the user.
    The password must be atleast six characters long.
  5. In the Repeat Password field, reenter the password for the user.
  6. Click Create.
    The dialog closes and the new user is added to the list.
Removing a user
Copy link
To remove a user:
  1. Click Users from the main menu.
    The Users page opens.
  2. Select the user to be deleted from the list.
  3. Click Delete User.
    A confirmation dialog opens.
  4. Click Yes.
    The dialog closes and the user is removed from the list.
Changing a user's password
Copy link
To change a user's password:
  1. Click Users from the main menu.
    The Users page opens.
  2. Select the user to update from the list.
  3. Click Change Password.
    The Change Password dialog opens.
  4. In the Password field, enter a password for the user.
    The password must be at least six characters long.
  5. In the Repeat Password field, reenter the password for the user.
  6. Click Change.
    The dialog closes and a message shows that the password was changed.
Adding a role to a user
Copy link
Note
Roles are not enforced.
To add a role to a user:
  1. Click Users from the main menu.
    The Users page opens.
  2. Select the user to update from the list.
  3. Click Add Role.
    The Add New Role dialog opens.
  4. In the Role Name field, enter a role for the user.
  5. Click Add.
    The dialog closes and a message shows that the role was added.
Deleting a role from a user
Copy link
Note
Roles are not enforced.
To delete a role from a user:
  1. Click Users from the main menu.
    The Users page opens.
  2. Select the user to update from the list.
    The user's roles are listed on the right side of the page.
  3. Click the X opposite the role to delete.
    A confirmation dialog opens.
  4. Click Yes.
    The dialog closes and the role is removed from the list.

16.1.2. Encrypting Stored Passwords
Copy link

Overview
Copy link
By default, the JAAS login modules store passwords as plain text. You can provide additional protection to passwords by storing them in an encrypted format. This can be done by adding the appropriate JAAS configuration to the profile defining the fabric's karaf realm. This can be done by adding the appropriate configuration properties to the org.fusesource.fabric.jaas PID and ensuring that they are applied to all of the containers in the fabric.
Note
Although message digest algorithms are not easy to crack, they are not invulnerable to attack (for example, see the Wikipedia article on cryptographic hash functions). Always use file permissions to protect files containing passwords, in addition to using password encryption.
Editing the default profile
Copy link
The easiest way to update all of the containers in a fabric is to modify the default profile. It is applied to all containers in a fabric through inheritance.
Important
Before making changes to the default profile, you should create a new profile version. Editing the active default profile could make your fabric unstable.
To enable password encryption by editing the default profile:
  1. Select the management console's Profiles tab.
  2. Create a new version by clicking Create Version.
    The Create New Version dialog appears.
  3. Optionally enter a name for the new version in the Name
    If you leave the Name field blank, the management console will use the name of the parent version and append the next available version number, starting from 1, to the name. For example, if version brokers1 existed, the management console would create version brokers1.1.
  4. From the Parent Version list, select the version from which the new version will originate.
    By default Use most recently created version is selected.
  5. Click Create to create the version.
    The dialog will close and the new version will be listed in the Versions table.
  6. Select the new version from the Versions list.
  7. Select the default profile from the Profiles list.
    The Profiles page for the selected profile opens.
  8. Select the Config Files tab.
  9. Select org.fusesource.fabric.jaas from the list.
    A text editing window opens.
  10. Enter values for the properties described in Table 16.1, “JAAS Encryption Properties” following the example shown in Example 16.1, “Password Encryption Configuration”.

    Example 16.1. Password Encryption Configuration

    encryption.enabled = true
encryption.name = jasypt
encryption.algorithm = SHA-256
encryption.encoding = base64
encryption.iterations = 100000
encryption.saltSizeBytes = 16
    Copy to Clipboard Toggle word wrap
  11. Click Save.
  12. If you configure the encryption to use Jasypt, add the jasypt-encryption feature to the profile.
    1. Select the Repositories tab.
    2. In the Add repository field enter mvn:org.apache.karaf.assemblies.features/standard/2.3.0.fuse-71-044/xml/features.
    3. Click Add.
    4. Select the Features tab.
    5. From the Repository list select mvn:org.apache.karaf.assemblies.features/standard/2.3.0.fuse-71-044/xml/features.
    6. From the Features list select jasypt-encryption.
  13. Select the management console's Containers tab.
  14. Click Migrate Containers.
  15. Click Select All.
  16. Select the version to which you added encryption from the Target Version table.
  17. Click Apply.
Configuration properties
Copy link
Table 16.1, “JAAS Encryption Properties” describes the properties used to enable password encryption.
Expand
Table 16.1. JAAS Encryption Properties
PropertyDescription
encryption.enabledSpecifies if password encryption is enabled.
encryption.nameSpecifies the name of the encryption service, which has been registered as an OSGi service. See the section called “Encryption services”.
encryption.prefixSpecifies the prefix for encrypted passwords.
encryption.suffixSpecifies the suffix for encrypted passwords.
encryption.algorithm
Specifies the name of the encryption algorithm—for example, MD5 or SHA-1. You can specify one of the following encryption algorithms:
  • MD2
  • MD5
  • SHA-1
  • SHA-256
  • SHA-384
  • SHA-512
encryption.encodingSpecifies the encrypted passwords encoding: hexadecimal or base64.
encryption.providerName (Jasypt only)Name of the java.security.Provider instance that is to provide the digest algorithm.
encryption.providerClassName (Jasypt only)Specifies the class name of the security provider that is to provide the digest algorithm.
encryption.iterations (Jasypt only)Specifies the number of times to apply the hash function recursively.
encryption.saltSizeBytes (Jasypt only)Specifies the size of the salt used to compute the digest.
encryption.saltGeneratorClassName (Jasypt only)Specifies the class name of the salt generator.
role.policySpecifies the policy for identifying role principals. Can have the values, prefix or group.
role.discriminatorSpecifies the discriminator value to be used by the role policy.
Encryption services
Copy link
An encryption service can be defined by inheriting from the org.apache.karaf.jaas.modules.EncryptionService interface and exporting an instance of the encryption service as an OSGi service. Two alternative implementations of the encryption service are provided:
  • Basic encryption service—installed in the standalone container by default and you can reference it by setting the encryption.name property to the value, basic. In the basic encryption service, the message digest algorithms are provided by the SUN security provider (the default security provider in the Oracle JDK).
  • Jasypt encryption—can be installed in the standalone container by installing the jasypt-encryption feature. To access the Jasypt encryption service, set the encryption.name property to the value, jasypt.
    For more information about Jasypt encryption, see the Jasypt documentation.

16.2. Defining JAAS Realms in a Fabric
Copy link

Overview
Copy link

Fabric containers, like standalone containers, use a special jaas:config element for defining JAAS realms. The difference is that when containers are deployed in a fabric, the JAAS realms need to be pushed out the fabric registry and all of the containers in the fabric need to share the same JAAS realms.

Procedure
Copy link

To change the JAAS realm used by the fabric containers for authentication:
  1. Create a Maven project to package and deploy the JAAS realm to the fabric's Maven proxy as shown in the section called “Creating a Maven project for deploying a JAAS realm”.
  2. Create a JAAS realm that uses the LDAP login module:
    1. Open the blueprint XML file in src/main/resources/OSGI-INF/my-service.xml in a text editor.
    2. Delete the bean and service elements.
    3. Add a jaas:config element to the blueprint.
  3. Deploy the JAAS realm to the fabric's maven proxy using the mvn deploy command.
  4. In the management console create a new profile for deploying the new realm.
    See chapter "Creating a New Profile" in "Using the Management Console".
  5. Select the Bundles tab.
  6. Add the bundle you uploaded for the JAAS realm to the profile.
    Bundles are specified using Maven URLs. For example if your project's group ID is my.jaas.realm and the artifact ID is jaas, the Maven URL for the bundle will be mvn:my.jaas.realm/ldap/version.
    See section "Editing a Profile's Bundles" in "Using the Management Console".
  7. Add the new profile to all of the containers in the fabric.
    See section "Adding a Profile to a Container" in "Using the Management Console".

Creating a Maven project for deploying a JAAS realm
Copy link

To create a Maven project for deploying a JAAS realm to a fabric registry:
  1. Use the karaf-blueprint-archetype archetype to generate a template project.
    Example 16.2, “Create a Maven Project” shows how to invoke the archetype from the command line.

    Example 16.2. Create a Maven Project

    mvn archetype:generate -DarchetypeGroupId=org.apache.karaf.archetypes -DarchetypeArtifactId=karaf-blueprint-archetype -DgroupId=groupID -DartifactId=artifactID
    Copy to Clipboard Toggle word wrap
  2. Remove the project's src/main/java folder.
    This folder holds template Java classes for implementing an OSGi service, but the JAAS realm does not require any Java classes.
  3. Open the project's POM in a text editor.
  4. Add a distributionManagement element, similar to the one shown in Example 16.3, “Fabric Maven Proxy Distribution Settings”, to the POM.

    Example 16.3. Fabric Maven Proxy Distribution Settings

    <distributionManagement>
  <repository>
    <id>fabric-maven-proxy</id>
    <name>FMC Maven Proxy</name>
    <url>http://username:password@localhost:8107/maven/upload/</url>
  </repository>
</distributionManagement>
    Copy to Clipboard Toggle word wrap
    You will need to modify the url element to include the connection details for your environment:

16.3. Enabling LDAP Authentication
Copy link

Revision History
12/05/12
modified the procedure to work in a fabric

Abstract

Fabric containers come with a preinstalled LDAP login module. To activate it you need to reconfigure the default JAAS realm to use the LDAP login module and associate the new realm with all of the containers in the fabric.

Overview
Copy link

Fabric containers supply a JAAS login module that enables it to use LDAP to authenticate users. The JAAS LDAP login module is implemented by the org.apache.karaf.jaas.modules.ldap.LDAPLoginModule class. It is preloaded by the containers, so you do not need to install its bundle.
To enable LDAP authentication, you need to create a new profile that redefines the default karaf realm to use the LDAP login module and deploy it to every container in the management console's fabric. Once this is done, all access to the management console Web console, and all of the fabric containers' command consoles, will be authenticated against your LDAP server.

Procedure
Copy link

To enable the fabric containers to use LDAP for user authentication:
  1. Create a Maven project to package and deploy the LDAP JAAS realm to the fabric's Maven proxy as shown in the section called “Creating a Maven project for deploying a JAAS realm”.
  2. Create a JAAS realm that uses the LDAP login module:
    1. Open the blueprint XML file in src/main/resources/OSGI-INF/my-service.xml in a text editor.
    2. Delete the bean and service elements.
    3. Add a jaas:config element to the blueprint.
    4. Add a name attribute to the jaas:config element and set its value to karaf.
      Note
      This will override the default realm used by the container.
    5. Add a rank attribute to the jaas:config element and set its value to 5.
      Note
      This will insure that this realm is used by the container.
    6. Add a jaas:module element to the jaas:config element.
    7. Add a className attribute to the jaas:module element and set its value to org.apache.karaf.jaas.modules.ldap.LDAPLoginModule.
      Example 16.4, “LDAP JAAS Login Module” shows the blueprint file.

      Example 16.4. LDAP JAAS Login Module

      <jaas:config ... >
  <jaas:module className="org.apache.karaf.jaas.modules.ldap.LDAPLoginModule"
               flags="required">
    ...
  </jaas:module>
</jaas:config>
      Copy to Clipboard Toggle word wrap
    8. Provide values for the properties described in section "Enabling LDAP Authentication" in "Security Guide".
  3. Deploy the JAAS realm to the fabric's maven proxy using the mvn deploy command.
  4. In the management console create a new profile for deploying the LDAP realm.
    See chapter "Creating a New Profile" in "Using the Management Console".
  5. Select the Bundles tab.
  6. Add the bundle you uploaded for the JAAS realm to the profile.
    Bundles are specified using Maven URLs. For example if your project's group ID is my.jaas.realm and the artifact ID is ldap, the Maven URL for the bundle will be mvn:my.jaas.realm/ldap/version.
    See section "Editing a Profile's Bundles" in "Using the Management Console".
  7. Add the new profile to all of the containers in the fabric.
    See section "Adding a Profile to a Container" in "Using the Management Console".

Chapter 17. Logging
Copy link

Abstract

The Red Hat JBoss Fuse runtime uses OPS4j Pax Logging as its logging mechanism. It is easily configured using the standard OSGi Admin mechanism and can be easily integrated with applications deployed in a container. The command console provides commands to manage the logs.
Red Hat JBoss Fuse uses the OPS4j Pax Logging system. Pax Logging is an open source OSGi logging service that extends the standard OSGi logging service to make it more appropriate for use in enterprise applications. It uses Apache Log4j as the back-end logging service. Pax Logging has its own API, but it also supports the following APIs:
  • Apache Log4j
  • Apache Commons Logging
  • SLF4J
  • Java Util Logging
For more information on OPS4j Pax Logging see http://team.ops4j.org/wiki/display/paxlogging/Pax+Logging.

17.1. Logging Configuration
Copy link

Overview
Copy link

The logging system is configured by a combination of two OSGi Admin PIDs and one configuration file:
  • etc/system.properties—the configuration file that sets the logging level during the container’s boot process. The file contains a single property, org.ops4j.pax.logging.DefaultServiceLog.level, that is set to ERROR by default.
  • org.ops4j.pax.logging—the PID used to configure the logging back end service. It sets the logging levels for all of the defined loggers and defines the appenders used to generate log output. It uses standard Log4j configuration. By default, it sets the root logger's level to INFO and defines two appenders: one for the console and one for the log file.
    Note
    The console's appender is disabled by default. To enable it, add log4j.appender.stdout.append=true to the configuration For example, to enable the console appender in a standalone container, you would use the following commands: 
    JBossFuse:karaf@root> config:edit org.ops4j.pax.logging
JBossFuse:karaf@root> config:propappend log4j.appender.stdout.append true
JBossFuse:karaf@root> config:update
    Copy to Clipboard Toggle word wrap
  • org.apache.karaf.log.cfg—configures the output of the log console commands.
The most common configuration changes you will make are changing the logging levels, changing the threshold for which an appender writes out log messages, and activating per bundle logging.

Changing the log levels
Copy link

The default logging configuration sets the logging levels so that the log file will provide enough information to monitor the behavior of the runtime and provide clues about what caused a problem. However, the default configuration will not provide enough information to debug most problems.
The most useful logger to change when trying to debug an issue with Red Hat JBoss Fuse is the root logger. You will want to set its logging level to generate more fine grained messages. To do so you change the value of the org.ops4j.pax.logging PID's log4j.rootLogger property so that the logging level is one of the following:
  • TRACE
  • DEBUG
  • INFO
  • WARN
  • ERROR
  • FATAL
  • NONE
Example 17.1, “Changing Logging Levels” shows the commands for setting the root loggers log level in a standalone container.

Example 17.1. Changing Logging Levels

JBossFuse:karaf@root> config:edit org.ops4j.pax.logging
JBossFuse:karaf@root> config:propset log4j.rootLogger "DEBUG, out, osgi:VmLogAppender"
JBossFuse:karaf@root> config:update
Copy to Clipboard Toggle word wrap

Changing the appenders' thresholds
Copy link

When debugging a problem in JBoss Fuse you may want to limit the amount of logging information that is displayed on the console, but not the amount written to the log file. This is controlled by setting the thresholds for each of the appenders to a different level. Each appender can have a log4j.appender.appenderName.threshold property that controls what level of messages are written to the appender. The appender threshold values are the same as the log level values.
Example 17.2, “Changing the Log Information Displayed on the Console” shows an example of setting the root logger to DEBUG but limiting the information displayed on the console to WARN.

Example 17.2. Changing the Log Information Displayed on the Console

JBossFuse:karaf@root> config:edit org.ops4j.pax.logging
JBossFuse:karaf@root> config:propset log4j.rootLogger "DEBUG, out, osgi:VmLogAppender"
JBossFuse:karaf@root> config:propappend log4j.appender.stdout.threshold WARN
JBossFuse:karaf@root> config:update
Copy to Clipboard Toggle word wrap

Logging per bundle
Copy link

It is possible to reconfigure JBoss Fuse logging so that it writes one log file for each bundle, instead of writing all of the log messages into a single log file. This feature is enabled by adding the Log4j sift appender to the Log4j root logger as shown in Example 17.3, “Enabling Per Bundle Logging”.

Example 17.3. Enabling Per Bundle Logging

JBossFuse:karaf@root> config:edit org.ops4j.pax.logging
JBossFuse:karaf@root> config:propset log4j.rootLogger "INFO, out, sift, osgi:VmLogAppender"
JBossFuse:karaf@root> config:update
Copy to Clipboard Toggle word wrap
After restarting the container, you can see that each BundleName bundle now has its own log file, located at data/log/BundleName.log.
This is the behavior you will see with the default sift appender settings. You can edit this behavior using the sift appender configuration settings in org.ops4j.pax.logging.cfg.

17.2. Logging per Application
Copy link

Overview
Copy link

Using Mapped Diagnostic Context (MDC) logging, you create a separate log file for each of your applications. The basic idea of MDC logging is that you associate each logging message with a particular context (for example, by associating it with a set of key-value pairs). Later on, when it comes to writing the log stream, you can use the context data to sort or filter the logging messages in various ways.
Note
MDC logging is supported only by log4j and slf4j.

Application key
Copy link

To use MDC logging, you must define a unique MDC key for each of your applications. The MDC key is a string that is associated with one application or logging context. At runtime, you can then use the application key to sort logging messages and write them into separate files for each application key.

Enabling per application logging
Copy link

To enable per application logging:
  1. In each of your applications, edit the Java source code to define a unique application key.
    If you are using slf4j, add the following static method call to your application: 
    org.slf4j.MDC.put("app.name","MyFooApp");
    Copy to Clipboard Toggle word wrap
    If you are using log4j, add the following static method call to your application: 
    org.apache.log4j.MDC.put("app.name","MyFooApp");
    Copy to Clipboard Toggle word wrap
  2. Edit the etc/org.ops4j.pax.logging PID to customize the sift appender.
    1. Set log4j.appender.sift.key to app.name.
    2. Set log4j.appender.sift.appender.file to =${karaf.data}/log/$\\{app.name\\}.log.
  3. Edit the etc/org.ops4j.pax.logging PID to add the sift appender to the root logger. 
    JBossFuse:karaf@root> config:edit org.ops4j.pax.logging
JBossFuse:karaf@root> config:propset log4j.rootLogger "INFO, out, sift, osgi:VmLogAppender"
JBossFuse:karaf@root> config:update
    Copy to Clipboard Toggle word wrap

17.3. Log Commands
Copy link

The Red Hat JBoss Fuse console provides the following commands for managing logging output:
log:display
Displays the most recent log entries. By default, the number of entries returned and the pattern of the output depends on the size and pattern properties in the org.apache.karaf.log.cfg file. You can override these using the -p and -d arguments.
log:display-exception
Displays the most recently logged exception.
log:get
Displays the current log level.
log:set
Sets the log level.
log:tail
Continuously display log entries .
log:clear
Clear log entries.

Chapter 18. Persistence
Copy link

Abstract

The Red Hat JBoss Fuse container caches information about its state and the artifacts deployed to it. It uses this data to make startup faster. You can configure how this information is stored on your file system.

Overview
Copy link

Red Hat JBoss Fuse containers store all of their persistent caches relative to its start location. It will create a data folder in the directory from which you launch the container. This folder is populated by folders storing information about the message broker used by the container, the OSGi framework, and the JBI container.

The data folder
Copy link

The data folder is used by the JBoss Fuse runtime to store persistent state information. It contains the following folders:
activemq
Contains persistent data needed by any Apache ActiveMQ brokers that are started by the container.
cache
The OSGi bundle cache. The cache contains a directory for each bundle, where the directory name corresponds to the bundle identifier number.
generated-bundles
Contains bundles that are generated by the container. Typically these are to support deployed JBI artifacts.
jbi
Contains a subdirectory for each JBI artifact deployed to the JBoss Fuse runtime. For JBI components the folder's name is generated by the component's name. For JBI service assemblies, the folder's name is the identifier of the bundle generated to support the service assembly.
log
Contains the log files.
maven
A temporary directory used by the Fabric Maven Proxy when uploading files.
txlog
Contains the log files used by the transaction management system. You can set the location of this directory in the org.apache.aries.transaction.cfg file

Changing the bundle cache location
Copy link

By default, the bundle cache is stored in InstallDir/data/cache.
To specify an alternative location, modify the org.osgi.framework.storage property in config.properties.
If you use a relative path, the cache location is added to the root of the JBoss Fuse installation directory.

Flushing the bundle cache
Copy link

You can configure JBoss Fuse to flush the bundle cache every time the runtime starts by setting the org.osgi.framework.storage.clean property to onFirstInit in config.properties. This property is set to none by default.

Changing the generated-bundle cache location
Copy link

The generated-bundle cache is where the container caches bundles it creates to support JARs that are not supplied as OSGi bundles.
You can configure the location of this cache by changing the felix.fileinstall.tmpdir property in the org.apache.felix.fileinstall-deploy.cfg file.

Adjusting the bundle cache buffer
Copy link

The felix.cache.bufsize property controls the size of the buffer used to copy bundles into the bundle cache. Its default value is 4096 bytes.
You can adjust this property by editing its value in the config.properties configuration file. The value is specified in bytes.

Chapter 19. Failover Deployments
Copy link

Abstract

Red Hat JBoss Fuse provides failover capability using either a simple lock file system or a JDBC locking mechanism. In both cases, a container-level lock system allows bundles to be preloaded into the slave kernel instance in order to provide faster failover performance.

19.1. Using a Simple Lock File System
Copy link

Overview
Copy link

When you first start Red Hat JBoss Fuse a lock file is created at the root of the installation directory. You can set up a master/slave system whereby if the master instance fails, the lock is passed to a slave instance that resides on the same host machine.

Configuring a lock file system
Copy link

To configure a lock file failover deployment, edit the etc/system.properties file on both the master and the slave installation to include the properties in Example 19.1, “Lock File Failover Configuration”.

Example 19.1. Lock File Failover Configuration

karaf.lock=true
karaf.lock.class=org.apache.karaf.main.SimpleFileLock
karaf.lock.dir=PathToLockFileDirectory
karaf.lock.delay=10000
Copy to Clipboard Toggle word wrap
  • karaf.lock—specifies whether the lock file is written.
  • karaf.lock.class—specifies the Java class implementing the lock. For a simple file lock it should always be org.apache.karaf.main.SimpleFileLock.
  • karaf.lock.dir—specifies the directory into which the lock file is written. This must be the same for both the master and the slave installation.
  • karaf.lock.delay—specifies, in milliseconds, the delay between attempts to reaquire the lock.

19.2. Using a JDBC Lock System
Copy link

Overview
Copy link

The JDBC locking mechanism is intended for failover deployments where Red Hat JBoss Fuse instances exist on separate machines.
In this scenario, the master instance holds a lock on a locking table hosted on a database. If the master loses the lock, a waiting slave process gains access to the locking table and fully starts its container.

Adding the JDBC driver to the classpath
Copy link

In a JDBC locking system, the JDBC driver needs to be on the classpath for each instance in the master/slave setup. Add the JDBC driver to the classpath as follows:
  1. Copy the JDBC driver JAR file to the ESBInstallDir/lib directory for each Red Hat JBoss Fuse instance.
  2. Modify the bin/karaf start script so that it includes the JDBC driver JAR in its CLASSPATH variable.
    For example, given the JDBC JAR file, JDBCJarFile.jar, you could modify the start script as follows (on a *NIX operating system): 
        ...
    # Add the jars in the lib dir
    for file in "$KARAF_HOME"/lib/karaf*.jar
    do
        if [ -z "$CLASSPATH" ]; then
            CLASSPATH="$file"
        else
            CLASSPATH="$CLASSPATH:$file"
        fi
    done
 CLASSPATH="$CLASSPATH:$KARAF_HOME/lib/JDBCJarFile.jar"
    Copy to Clipboard Toggle word wrap
    Note
    If you are adding a MySQL driver JAR or a PostgreSQL driver JAR, you must rename the driver JAR by prefixing it with the karaf- prefix. Otherwise, Apache Karaf will hang and the log will tell you that Apache Karaf was unable to find the driver.

Configuring a JDBC lock system
Copy link

To configure a JDBC lock system, update the etc/system.properties file for each instance in the master/slave deployment as shown

Example 19.2. JDBC Lock File Configuration

karaf.lock=true
karaf.lock.class=org.apache.karaf.main.DefaultJDBCLock
karaf.lock.level=50
karaf.lock.delay=10
karaf.lock.jdbc.url=jdbc:derby://dbserver:1527/sample
karaf.lock.jdbc.driver=org.apache.derby.jdbc.ClientDriver
karaf.lock.jdbc.user=user
karaf.lock.jdbc.password=password
karaf.lock.jdbc.table=KARAF_LOCK
karaf.lock.jdbc.clustername=karaf
karaf.lock.jdbc.timeout=30
Copy to Clipboard Toggle word wrap
In the example, a database named sample will be created if it does not already exist. The first Red Hat JBoss Fuse instance to acquire the locking table is the master instance. If the connection to the database is lost, the master instance tries to gracefully shutdown, allowing a slave instance to become master when the database service is restored. The former master will require manual restart.

Configuring JDBC locking on Oracle
Copy link

If you are using Oracle as your database in a JDBC locking scenario, the karaf.lock.class property in the etc/system.properties file must point to org.apache.karaf.main.OracleJDBCLock.
Otherwise, configure the system.properties file as normal for your setup, as shown:

Example 19.3. JDBC Lock File Configuration for Oracle

karaf.lock=true 
karaf.lock.class=org.apache.karaf.main.OracleJDBCLock 
karaf.lock.jdbc.url=jdbc:oracle:thin:@hostname:1521:XE 
karaf.lock.jdbc.driver=oracle.jdbc.OracleDriver 
karaf.lock.jdbc.user=user 
karaf.lock.jdbc.password=password 
karaf.lock.jdbc.table=KARAF_LOCK 
karaf.lock.jdbc.clustername=karaf 
karaf.lock.jdbc.timeout=30
Copy to Clipboard Toggle word wrap
Note
The karaf.lock.jdbc.url requires an active Oracle system ID (SID). This means you must manually create a database instance before using this particular lock.

Configuring JDBC locking on Derby
Copy link

If you are using Derby as your database in a JDBC locking scenario, the karaf.lock.class property in the etc/system.properties file should point to org.apache.karaf.main.DerbyJDBCLock. For example, you could configure the system.properties file as shown:

Example 19.4. JDBC Lock File Configuration for Derby

karaf.lock=true
karaf.lock.class=org.apache.karaf.main.DerbyJDBCLock
karaf.lock.jdbc.url=jdbc:derby://127.0.0.1:1527/dbname
karaf.lock.jdbc.driver=org.apache.derby.jdbc.ClientDriver
karaf.lock.jdbc.user=user
karaf.lock.jdbc.password=password
karaf.lock.jdbc.table=KARAF_LOCK
karaf.lock.jdbc.clustername=karaf
karaf.lock.jdbc.timeout=30
Copy to Clipboard Toggle word wrap

Configuring JDBC locking on MySQL
Copy link

If you are using MySQL as your database in a JDBC locking scenario, the karaf.lock.class property in the etc/system.properties file must point to org.apache.karaf.main.MySQLJDBCLock. For example, you could configure the system.properties file as shown:

Example 19.5. JDBC Lock File Configuration for MySQL

karaf.lock=true
karaf.lock.class=org.apache.karaf.main.MySQLJDBCLock
karaf.lock.jdbc.url=jdbc:mysql://127.0.0.1:3306/dbname
karaf.lock.jdbc.driver=com.mysql.jdbc.Driver
karaf.lock.jdbc.user=user
karaf.lock.jdbc.password=password
karaf.lock.jdbc.table=KARAF_LOCK
karaf.lock.jdbc.clustername=karaf
karaf.lock.jdbc.timeout=30
Copy to Clipboard Toggle word wrap

Configuring JDBC locking on PostgreSQL
Copy link

If you are using PostgreSQL as your database in a JDBC locking scenario, the karaf.lock.class property in the etc/system.properties file must point to org.apache.karaf.main.PostgreSQLJDBCLock. For example, you could configure the system.properties file as shown:

Example 19.6. JDBC Lock File Configuration for PostgreSQL

karaf.lock=true
karaf.lock.class=org.apache.karaf.main.PostgreSQLJDBCLock
karaf.lock.jdbc.url=jdbc:postgresql://127.0.0.1:5432/dbname
karaf.lock.jdbc.driver=org.postgresql.Driver
karaf.lock.jdbc.user=user
karaf.lock.jdbc.password=password
karaf.lock.jdbc.table=KARAF_LOCK
karaf.lock.jdbc.clustername=karaf
karaf.lock.jdbc.timeout=0
Copy to Clipboard Toggle word wrap

JDBC lock classes
Copy link

The following JDBC lock classes are currently provided by Apache Karaf: 
org.apache.karaf.main.DefaultJDBCLock
org.apache.karaf.main.DerbyJDBCLock
org.apache.karaf.main.MySQLJDBCLock
org.apache.karaf.main.OracleJDBCLock
org.apache.karaf.main.PostgreSQLJDBCLock
Copy to Clipboard Toggle word wrap

19.3. Container-level Locking
Copy link

Overview
Copy link

Container-level locking allows bundles to be preloaded into the slave kernel instance in order to provide faster failover performance. Container-level locking is supported in both the simple file and JDBC locking mechanisms.

Configuring container-level locking
Copy link

To implement container-level locking, add the following to the etc/system.properties file on each system in the master/slave setup:

Example 19.7. Container-level Locking Configuration

karaf.lock=true
karaf.lock.level=50
karaf.lock.delay=10
Copy to Clipboard Toggle word wrap
The karaf.lock.level property tells the Red Hat JBoss Fuse instance how far up the boot process to bring the OSGi container. Bundles assigned the same start level or lower will then also be started in that JBoss Fuse instance.
Bundle start levels are specified in etc/startup.properties, in the format BundleName.jar=level. The core system bundles have levels below 50, where as user bundles have levels greater than 50.
Expand
Table 19.1. Bundle Start Levels
Start Level Behavior
1A 'cold' standby instance. Core bundles are not loaded into container. Slaves will wait until lock acquired to start server.
<50A 'hot' standby instance. Core bundles are loaded into the container. Slaves will wait until lock acquired to start user level bundles. The console will be accessible for each slave instance at this level.
>50This setting is not recommended as user bundles will be started.

Avoiding port conflicts
Copy link

When using a 'hot' spare on the same host you need to set the JMX remote port to a unique value to avoid bind conflicts. You can edit the servicemix start script (or the karaf script on a child instance) to include the following: 
DEFAULT_JAVA_OPTS="-server $DEFAULT_JAVA_OPTS -Dcom.sun.management.jmxremote.port=1100 -Dcom.sun.management.jmxremote.authenticate=false"
Copy to Clipboard Toggle word wrap

Abstract

The JBI components included in Red Hat JBoss Fuse use a thread pool to process message exchanges. You can configure each component's thread pool independently.

Overview
Copy link

The JBI components are multi-threaded. Each one maintains a thread pool that it uses to process message exchanges. These thread pools are configured using three properties that control the minimum number of threads in the pool, the maximum number of threads in the pool, and the depth of the component's job queue.

Component configuration PIDs
Copy link

The thread pool properties can be customised for a particular JBI component, ComponentName, by adding the relevant PID to the OSGi Admin service. Each JBI component has a corresponding PID that matches the pattern org.apache.servicemix.components.ComponentName.
The thread pool properties can also be configured using a JMX console.
Important
The component needs to be restarted for changes to take effect.

Thread pool properties
Copy link

Table 20.1, “Component Thread Pool Properties” lists the properties used to configure component thread properties.
Expand
Table 20.1. Component Thread Pool Properties
PropertyDefaultDescription
corePoolSize8Specifies the minimum number of threads in a thread pool. If the number of available threads drops below this limit, the runtime will always create a new thread to handle the job.
maximumPoolSize32Specifies the maximum number of threads in a thread pool. Setting this property to -1 specifies that it is unbounded.
queueSize256Specifies the number of jobs allowed in a component's job queue.

Thread selection
Copy link

When a component receives a new message exchange it choose the thread to process the exchange as follows:
  1. If the component's thread pool is smaller than the corePoolSize, a new thread is created to process the task.
  2. If less than queueSize jobs are in the component's job queue, the task is placed on the queue to wait for a free thread.
  3. If the component's job queue is full and the thread pool has less than maximumPoolSize threads instantiated, a new thread is created to process the task.
  4. The job is processed by the current thread.

Example
Copy link

Example 20.1, “Component Thread Pool Configuration” shows the configuration for a component whose thread pool can have between 10 and 200 threads.

Example 20.1. Component Thread Pool Configuration

corePoolSize = 10
maximumPoolSize = 200
...
Copy to Clipboard Toggle word wrap

Chapter 21. Applying Patches
Copy link

Abstract

Red Hat JBoss Fuse supports incremental patching. FuseSource will supply you with easy to install patches that only make targeted changes to a deployed container.
Incremental patching allows you apply targets fixes to a container without needing to reinstall an updated version of Red Hat JBoss Fuse. It also allows you to easily back the patch out if it causes problems with your deployed applications.
Patches are ZIP files that contain the artifacts needed to update a targeted set of bundles in a container. The patch file includes a .patch file that lists the contained artifacts. The artifacts are typically one or more bundles. They can, however, include configuration files and feature descriptors.
You get a patch file in one of the following ways:
  • Customer Support sends you a patch.
  • Customer Support sends you a link to download a patch.
The process of applying a patch to a container depends on how the container is deployed:
  • standalone—the container's command console's patch shell has commands for managing the patching process
  • fabric—patching a fabric requires applying the patch to a profile and then applying the profile to a container
    The management console is the recommended way to patch containers in a fabric. See Using the Management Consolefor more information.

21.1. Patching a Standalone Container
Copy link

Abstract

You apply patches to a standalone container using the command console's patch shell. You cam apply and roll back patches as needed.

Overview
Copy link

Patching a standalone container directs the container to load the patch versions of artifacts instead of the non-patch versions. The chapter "Patch Console Commands" in "Console Reference" shell provides commands to patches to the container's environment, see which bundles are effected by applying the patch, apply the patch to the container, and back the patch out if needed.
To make sure that the a patch can be rolled back Red Hat JBoss Fuse applies the patch in a non-destructive manner. The patching process does not overwrite the artifacts included in the original installation. The patched artifacts are placed in the container's system folder. When the patch is applied, the container's configuration is changed so that it points to the patched artifacts instead of the artifacts from the original installation. This makes it easy for the system to be restored to its original state or to selectively back out patches.
Important
Patches do not persist across installations. If you delete and reinstall a JBoss Fuse instance you will need to download the patches and reapply them.

Applying a patch
Copy link

To apply a patch to a standalone container:
  1. Add the patch to the container's environment using the section "Arguments" in "Console Reference" command.
    Example 21.1, “Adding a Patch to a Broker's Environment” shows the command for adding the patch contained in the patch file patch.zip from the local file system.

    Example 21.1. Adding a Patch to a Broker's Environment

    JBossA-MQ> patch:add file://patch.zip
    Copy to Clipboard Toggle word wrap
    This command copies the specified patch file to the container's system folder and unpacks it.
  2. Simulate installing the patch using the section "Arguments" in "Console Reference" command.
    This will generate a log of the changes that will be made to the container when the patch is installed, but will not make any actual changes to the container.
    Note
    The section "Arguments" in "Console Reference" command displays a list of all patches added to the container's system folder.
  3. Review the simulation log to understand the changes that will be made to the container.
  4. Apply the patch to the container using the section "Arguments" in "Console Reference" command.
    Warning
    Running patch:install before the container is fully started and all of the bundles are active will cause the container to hang.
    Note
    The section "Arguments" in "Console Reference" command displays a list of all patches added to the container's system folder.
The container will need to restart to apply the patch. If you are using a remote console, you will lose the connection to the container. If you are using the container's local console, it will automatically reconnect when the container restarts.

Rolling back a patch
Copy link

Occasionally a patch will not work or introduce new issues to a container. In these cases you can easily back the patch out of the system and restore it pre-patch behavior using the section "Arguments" in "Console Reference" command. As shown in Example 21.2, “Rolling Back a Patch”, the command takes the name of patch to be backed out.

Example 21.2. Rolling Back a Patch

JBossA-MQ> patch:rollback patch1
Copy to Clipboard Toggle word wrap
Note
The section "Arguments" in "Console Reference" command displays a list of all patches added to the container's system folder.
The container will need to restart to rollback the patch. If you are using a remote console, you will lose the connection to the container. If you are using the container's local console, it will automatically reconnect when the container restarts.

21.2. Patching a Container in a Fabric
Copy link

Abstract

In a fabric patches are applied to profiles and the patched version of the profile is applied to the container. The management console is the recommended tool for patching containers in a fabric. The fabric shell also has the commands needed to apply a patch and roll it out to running containers.

Overview
Copy link

The bundles loaded by a container in a fabric is controlled by the container's Fabric Agent. The agent inspects the profiles applied to the container to determine what bundles to load, and the version of each bundle, and then loads the specified version of each bundle for the container.
A patch typically includes a new version of one or more bundles, so to apply the patch to container in a fabric you need to update the profiles applied to it. This will cause the Fabric Agent to load the patched versions of the bundles.
The management console is the recommended tool for patching containers in a fabric. However, the command console's fabric shell also provides the commands needed to patch containers running in a fabric.

Procedure
Copy link

Patching a container in a fabric involves:
  1. Getting a patch file.
    • Customer Support sends you a patch.
    • Customer Support sends you a link to download a patch.
    • You, or your organization, generate a patch file for an internally created application.
  2. Uploading one or more patch files to the fabric's Maven repository.
  3. Applying the patch(es) to a profile version.
    This creates a new profile version that points to the new versions of the patched bundles and repositories.
  4. Migrate one or two containers to the patched profile version to ensure that the patch does not introduce any new issues.
  5. After you are certain that the patch works, migrate the remaining containers in the fabric to the patched version.

Using the management console
Copy link

The management console is the easiest and most verbose method of patching containers in a fabric. Its Patching tab uploads patches to a fabric's Maven repository and applies the patch to a specified profile version. You can then use the management console to roll the patch out to all of the containers in the fabric.
See Using the Management Console for more information.

Using the command console
Copy link

The Red Hat JBoss Fuse command console can also be used to patch containers running in a fabric. To patch a fabric container:
  1. Upload the patch file to the fabric's Maven repository.
  2. Create a new profile version to which the patch will be applied.
  3. Modify all of the profiles in the new version which require the patch.
  4. Use the fabric:container-upgrade command to roll the patch out to the containers running in the fabric.

Applying patches P3 or later to JBoss Fuse A-MQ 6.0
Copy link

If you need to apply patch P3 or later to JBoss Fuse A-MQ 6.0, you must first apply the P3 prerequisite patch before applying the patch. The P3 prerequisite patch is a fix to the fabric-agent bundle that resolves a patching bug. This is applicable only to fabric environments and the patch must be applied before applying any patch P3 or higher. Once a container has been patched with the P3 prerequisite patch, it does not need to be installed again before applying any new patches.
For example, to apply the P3 patch to a fresh installation of JBoss A-MQ 6.0, you would perform the following steps:
  1. Apply the P3 prerequisite patch, using the patching process described in this section.
  2. Apply the P3 patch, using the patching process described in this section.

Applying rollup patches to JBoss Fuse A-MQ 6.0
Copy link

The P3 prerequisite patch must also be installed before installing a rollup patch to JBoss Fuse A-MQ 6.0. In other words, the rollup patches do not incorporate the P3 prerequisite patch.

Chapter 22. Configuring a Fabric's Maven Proxy
Copy link

Abstract

The Fabric Ensemble creates a Maven proxy to access the repositories from which artifacts are distributed to the fabric's containers. You can modify the default settings to use a different set of repositories or the make an internal repository accessible.

Overview
Copy link

The Fabric Ensemble creates a Maven proxy to facilitate access to the artifacts required by the containers in the fabric. Each Fabric Server deployed in the fabric runs an instance of a Maven proxy. The ensemble aggregates all of the proxies so that it appears to the Fabric Agents as a single Maven proxy.
The Fabric Agents use the fabric's Maven proxy to access the known repositories. This ensures that all of the containers use the same set of repositories and artifacts.
Note
Advanced users can configure each Fabric Server to act as a proxy for a different set of repositories. However, this is not a recommended set up.
Note
Red Hat JBoss Fuse IDE provides tooling for uploading bundles using the Maven proxy. You can also add the fabric's Maven Proxy to a POM file so that bundles can be distributed to the ensemble as part of an automated build process.

Default repositories
Copy link

By default a fabric's Maven proxy is configured to be a proxy for the following Maven repositories:
  • Maven Central (http://repo1.maven.org/maven2)
  • Fuse Releases (http://repo.fusesource.com/nexus/content/repositories/releases)
  • Fuse Early Access (http://repo.fusesource.com/nexus/content/groups/ea)
  • SpringSource (http://repository.springsource.com/maven/bundles/release, http://repository.springsource.com/maven/bundles/external)
  • Scala Tools (http://scala-tools.org/repo-releases)
  • User's Local (~/.m2/repository)

Changing the repositories
Copy link

To change the repositories the ensemble proxies:
  1. Create a new profile version.
    From the command console this is done using the fabric:version-create command. See section "Description" in "Console Reference" for more information.
  2. Change the org.ops4j.pax.url.mvn.repositories property in the org.fusesource.fabric.agent PID of the default profile. Example 22.1, “Configuring the Maven Proxy URL” shows the console command for editing this property.

    Example 22.1. Configuring the Maven Proxy URL

    JBossFuse:karaf@root> fabric:profile-edit -p org.fusesource.fabric.agent/org.ops4j.pax.url.mvn.repositories= \ http://repo1.maven.org/maven2, \ http://repo.fusesource.com/nexus/content/repositories/releases, \ http://repo.fusesource.com/nexus/content/groups/ea, \ http://repository.springsource.com/maven/bundles/release, \ http://repository.springsource.com/maven/bundles/external, \ http://scala-tools.org/repo-releases default
    Copy to Clipboard Toggle word wrap
    Note
    The org.fusesource.fabric.agent PID is refined in all of the fabric profiles. Setting the proxy URL, the org.ops4j.pax.url.mvn.repositories property, in the default profile ensures that all of the other fabric profiles share the same Maven proxy setting.
    Important
    The fabric profile's org.fusesource.fabric.maven PID, which ultimately controls the Maven proxy, imports its value from the default profile's org.fusesource.fabric.agent PID. You should not change the settings of the org.fusesource.fabric.maven PID.
  3. Roll the changes out the fabric by upgrading the containers to the new profile version.
    Important
    You cannot test this configuration change out on a few containers to validate it. The change must be made to the entire fabric or it will result in conflicts.

Index
Copy link

A

admin commands, Using the admin console commands

B

broker
deploying
fabric container, Fabric containers
standalone container, Standalone containers
bundle cache, Changing the bundle cache location

C

child containers, Managing Child Containers
config shell, Standalone containers
config.properties, OSGi framework properties, Overview
config:list, Listing the current configuration
configuration
files, Configuration files
JBI, JBI component configuration
OSGi, Introducing Red Hat JBoss Fuse Configuration

F

fabric shell, Fabric containers
fabric:container-stop, Shutting Down a Fabric
fabric:container-upgrade, Using the command console
fabric:join, Joining a Fabric
fabric:mq-create, Fabric containers
failover, Failover Deployments
featureRepositories, Modifying the default set of feature URLs
featuresBoot, Modifying the default installed features
felix.cache.bufsize, Adjusting the bundle cache buffer
felix.fileinstall.dir, Specifying the hot deployment folder
felix.fileinstall.poll, Specifying the scan interval
felix.fileinstall.tmpdir, Changing the generated-bundle cache location

G

generated bundle cache, Changing the generated-bundle cache location

H

hot deployment
folder, Specifying the hot deployment folder
monitor interval, Specifying the scan interval
HTTPS
client authentication needed, Enabling HTTPS
client authentication wanted, Enabling HTTPS
HTTPS configuration, Enabling HTTPS

J

JBI
configuration, JBI component configuration
JDBC lock, Using a JDBC Lock System
JMX configuration
url, Changing the RMI port and JMX URL

K

karaf.default.repository, Initial container properties
karaf.framework, OSGi framework properties
karaf.framework.felix, OSGi framework properties
karaf.name, Initial container properties
KARAF_BASE, Specifying the Red Hat JBoss Fuse's environment
KARAF_DATA, Specifying the Red Hat JBoss Fuse's environment
KARAF_HOME, Specifying the Red Hat JBoss Fuse's environment

L

launching
client mode, Launching the runtime in client mode
default mode, Launching the runtime
server mode, Launching the runtime in server mode
LDAP
enabling, Enabling LDAP Authentication
LDAPLoginModule, Enabling LDAP Authentication
lock file, Using a Simple Lock File System
logging
commands, Log Commands

M

mq-create, Fabric containers

O

org.apache.felix.fileinstall-deploy, Overview
org.apache.karaf.log, Overview
org.fusesource.fabric.agent, Changing the repositories
org.fusesource.fabric.maven, Changing the repositories
org.ops4j.pax.logging, Overview
org.ops4j.pax.logging.DefaultServiceLog.level, Overview
org.ops4j.pax.url.mvn.repositories, Changing the repositories
org.ops4j.pax.web.ssl.clientauthneeded, Enabling HTTPS
org.ops4j.pax.web.ssl.clientauthwanted, Enabling HTTPS
org.ops4j.pax.web.ssl.keypassword, Enabling HTTPS
org.ops4j.pax.web.ssl.keystore, Enabling HTTPS
org.ops4j.pax.web.ssl.keystore.type, Enabling HTTPS
org.ops4j.pax.web.ssl.password, Enabling HTTPS
org.osgi.framework.storage, Changing the bundle cache location
org.osgi.framework.storage.clean, Flushing the bundle cache
org.osgi.service.http.enabled, Enabling HTTPS
org.osgi.service.http.port, Initial container properties
org.osgi.service.http.port.secure, Enabling HTTPS
org.osgi.service.http.secure.enabled, Enabling HTTPS
OSGi
configuration, Introducing Red Hat JBoss Fuse Configuration
OSGi configuration
creating, Standalone containers
OSGi framework
configuring, OSGi framework properties

P

patch:add, Applying a patch
patch:install, Applying a patch
patch:list, Applying a patch, Rolling back a patch
patch:rollback, Rolling back a patch
patch:simulate, Applying a patch
patching
fabric
command console, Using the command console
management console, Using the management console
standalone, Applying a patch
rollback, Rolling back a patch
profile
creating, Fabric containers

R

remote client, Using the remote client
remote console
address, Configuring a container for remote access
ssh, Using the ssh:ssh console command
remoteShellLocation, Configuring a container for remote access
RMI port, Changing the RMI port and JMX URL
RMI registry
port number, Changing the RMI port and JMX URL
rmiRegistryPort, Changing the RMI port and JMX URL

S

security, Configuring JAAS Security
service wrapper
classpath, Adding classpath entries
JMX configuration, JMX configuration
JVM properties, Passing parameters to the JVM
logging, Configuring logging
serviceUrl, Changing the RMI port and JMX URL
standalone
initial features, Configuring the Initial Features in a Standalone Container
starting, Starting Red Hat JBoss Fuse
stopping, Stopping Red Hat JBoss Fuse
remote container, Stopping a Remote Container
system service
Redhat, Redhat Linux
Ubuntu, Ubuntu Linux
Windows, Windows
system.properties, Initial container properties

X

X.509
configuration, Enabling HTTPS

Legal Notice
Copy link

Trademark Disclaimer

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, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Apache, ServiceMix, Camel, CXF, and ActiveMQ are trademarks of Apache Software Foundation. Any other names contained herein may be trademarks of their respective owners.

Legal Notice
Copy link

Third Party Acknowledgements

One or more products in the Red Hat JBoss Fuse release includes third party components covered by licenses that require that the following documentation notices be provided:
  • JLine (http://jline.sourceforge.net) jline:jline:jar:1.0
    License: BSD (LICENSE.txt) - Copyright (c) 2002-2006, Marc Prud'hommeaux
    All rights reserved.
    Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
    • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
    • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
    • Neither the name of JLine nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  • Stax2 API (http://woodstox.codehaus.org/StAX2) org.codehaus.woodstox:stax2-api:jar:3.1.1
    License: The BSD License (http://www.opensource.org/licenses/bsd-license.php)
    Copyright (c) <YEAR>, <OWNER> All rights reserved.
    Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
    • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
    • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  • jibx-run - JiBX runtime (http://www.jibx.org/main-reactor/jibx-run) org.jibx:jibx-run:bundle:1.2.3
    License: BSD (http://jibx.sourceforge.net/jibx-license.html) Copyright (c) 2003-2010, Dennis M. Sosnoski.
    All rights reserved.
    Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
    • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
    • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
    • Neither the name of JiBX nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  • JavaAssist (http://www.jboss.org/javassist) org.jboss.javassist:com.springsource.javassist:jar:3.9.0.GA:compile
    License: MPL (http://www.mozilla.org/MPL/MPL-1.1.html)
  • HAPI-OSGI-Base Module (http://hl7api.sourceforge.net/hapi-osgi-base/) ca.uhn.hapi:hapi-osgi-base:bundle:1.2
    License: Mozilla Public License 1.1 (http://www.mozilla.org/MPL/MPL-1.1.txt)
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat