Red Hat Training

A Red Hat training course is available for Red Hat JBoss Operations Network

10.2. Creating a Content Source

A content source is whatever mechanism supplies software packages to JBoss ON and, through JBoss ON's content management, to resources. JBoss ON supports several different types of content sources.

Table 4. Types of Content Sources

Source Type Description Requires Credentials?
Remote URL Downloads from a remote URL. This can use a couple of different protocols, such as FTP. No
HTTP Similar to the Remote URL content source, connects over a network connection to the source. This uses specifically the HTTP protocol.
The HTTP content source can also connect to an HTTP proxy.
HTTPS is not supported.
Optionally allows credentials to log into the given HTTP site or the proxy server[a]
JBoss Customer Portal Feed (RSS) Similar to the Remote URL content source, except that it works specifically with the Customer Portal RSS feed for JBoss cumulative patches. Yes[a]
Local Disk Connects to a single local directory (on the local system or NFS-mounted) and looks for packages of the specified type and architecture to download. No
[a] Any passwords given in the content source configuration are obfuscated in the JBoss ON database.

10.2.1. Creating a Content Source (General)

  1. In the top menu, click the Administration tab.
  2. In the Content menu table on the left, select the Content Sources item.
  3. Below the list of current content sources, click the CREATE NEW button.
  4. Select the content source type, which defines how the content is delivered from the source. Table 4, “Types of Content Sources” describes the different content sources.
  5. When the content source type is selected, a form automatically opens to fill in the basic details and configuration for the resource. These basic details identify the content source in the JBoss ON server and are the same for each content source type, while the configuration is specific to the content source type.
    • Give a unique name and optional description for the content source provider.
    • The schedule sets how frequently the content in the JBoss ON database is updated by the content source; this uses a standard Quartz Cron Syntax.
    • The lazy load setting sets whether to download packages only when they are installed (Yes) or if all packages should be download immediately.
    • The download mode sets how the content is stored in JBoss ON. The default is DATABASE, which stores all packages in the JBoss ON database instance. The other options are to store the packages on a network filesystem or not to store them at all.
  6. Fill in the other configuration information for the content source. The required information varies depending on the content source type. This is going to require some kind of connection information, such as a URL or directory path, and possibly authentication information, like a username and password.


    Any passwords stored for content sources are obfuscated in the JBoss ON database.

10.2.2. Enabling the Default JBoss Patch Content Source

For JBoss patches, the default content provider connects the JBoss ON server to the cumulative patches provided by the JBoss Customer Service Portal. The default repository associated with the content provider is where the metadata about the patches and the patches themselves are stored within JBoss ON.
The JBoss ON agent is the entity which actually executes the patching process on a resource. The agent is informed of updates, pulls the information from the server, and then updates the local JAR and class files within the managed JBoss instance. The patching process runs independently of any server configuration profile or base configuration.
JBoss products can receive and apply patch updates through the JBoss Customer Portal feed in JBoss ON. The supported products include:
  • JBoss Enterprise Application Platform (EAP)
  • JBoss Enterprise Web Platform and Web Services (EWP and EWS)
  • JBoss Enterprise Data Services (EDS)
  • JBoss SOA Platform (SOA-P)


A Customer Portal feed is only available for a product or a specific version of a product if there is a patch in the Customer Portal for that product. JBoss ON depends on the JBoss Customer Portal to provide patch information.


Perform patch installations during off hours or scheduled maintenance periods.
  1. In the Administration tab in the top menu, open the Content menu and select the Content Sources item.
  2. Click the JBoss Customer Portal Patch Feed source.
  3. Click the Edit button at the bottom of the Customer Portal Feed Settings area to modify the content source.
  4. Fill in the required connection information.
    Most of the default settings, such as the schedule, can be kept.


    Keep the Lazy Load checkbox activated, or all patches defined in the RSS feed, 1 GB of data, is preemptively downloaded by the JBoss ON server.
  5. Click Save.
  6. Optionally, use Synchronize button to force the content source to pull down the latest RSS Feed and synchronize it with the local data. The history of synchronization attempts is listed in the Synchronization Results section.
  7. Perform any manual steps to complete the patch installation.
    Some patches require additional, manual changes, such as editing an XML configuration file. There are several different situations that require manual intervention:
    • The file to be patched is not present in the configuration.
    • There are files that need to be removed manually.
    • Configuration files, such as XML or Java properties files, require patches that need to be applied manually.
    • Seam is being used and must be patched manually.
    Basically, admin intervention is required to resolve anything that is outside the default configuration, like merging in custom configuration or updating custom libraries.
    JBoss ON performs the standard steps required to apply patches to a JBoss instance, but it does not (and should not) have any way to parse and then merge changes in the configuration. JBoss ON does not attempt to determine, value, and apply custom changes. That sort of heuristic is best performed by an administrator.
    Any manual steps which are required to complete the patch are listed in the content update summary after the patch is applied.

10.2.3. Creating a Content Source (Local Disk)

A local disk content source is set up more or less as described in Section 10.2.1, “Creating a Content Source (General)”, but the values for both the content source setup and the repository setup are critical for content synchronization to work.
A single content source can be associated with multiple repositories, and this is true for local disk configuration. For local disk providers, the content source defines a root directory, and then the repository name identifies the subdirectory which contains the packages.
Local Disk Structure

Figure 9. Local Disk Structure

This structure allows multiple repositories to use the same base directory in the content provider.
JBoss ON derives the information for the local disk based on the combination of the content source configuration (root directory) and the repository configuration (subdirectory). For the sync to work, the repository must have the identical name as the subdirectory which contains the packages.


Each subdirectory name must be unique through the hierarchy of the root directory tree. For example, there should not be directories named /export/myContentSource/test and /export/myContentSource/subdir/test.
Having two directories, even at different levels, with the same name can result in unpredictable package sync behavior.
To set up the local disk provider:
  1. Note

    If the subdirectories to sync already exist, then the content source configuration prompts for possible repositories to associate with the local disk provider based on the subdirectory names.
  2. Enter the root directory path.
  3. Enter the content package information, which the JBoss ON server uses to identify the packages to pull into the content storage.
  4. Create the repository, as in Section 10.3.1, “Creating a Repository”, and give it the name of the subdirectory to use.


    Each subdirectory name must be unique through the hierarchy of the root directory tree. For example, there should not be directories named /export/myContentSource/test and /export/myContentSource/subdir/test.
    Having two directories, even at different levels, with the same name can result in unpredictable package sync behavior.
  5. Create the subdirectory on the local system, and copy in the packages which should be added to the JBoss ON content system.