The GUI has been redesigned in JBoss ON 3.0, moving from an older JavaScript/Struts design to GWT 2.0.4 and SmartGWT 2.4. The new GUI includes new stylesheets and a more efficient Ajax architecture, preserving a familiar layout with a cleaner and more responsive experience.

The top navigation menu has been updated to focus on clearer and more relevant tasks, adding new Bundles and Reporting tabs. Additionally, the previous top-level menus have been removed and replaced with context-specific task panes in the left navigation area. This makes it simpler to locate configuration areas. Even tables are now easier to manage, with improved sort and the ability to change the information displayed in the table columns.

One of the key features for administrative management is a more dynamic dashboard, including the ability to have multiple, user-customized dashboards in the primary Dashboard area and customizable resource-level dashboards on resource Summary tabs.

The new design brings other benefits:

Much of the JBoss ON configuration management is designed around implementing changes for resources by editing configuration files or updating files and packages. But another aspect of managing configuration is detecting unplanned, unapproved changes. The ideal configuration for a server includes defining file settings, software versions, and system settings. Resource configuration will change naturally over time, but administrators need to track those changes that could impact performance or availability. Defining a baseline configuration and tracking changes helps systems remain resilient, compliant, and understandable.

Unplanned changes to a resource's configuration are called drift, the movement away from the designated configuration baseline. JBoss Operations Network's drift management offers a way to identify and track these changes and to revert to previous versions if necessary. Drift management is a blend between JBoss ON's configuration management (which manages file settings), its content management (package lists, individual files, and versions), and monitoring.

Drift management is driven by a drift definition that defines:

Along with resource-level drift definitions, JBoss ON also supports drift definition templates, which allows default settings that can be applied to multiple resources.

Once a drift definition is created, JBoss ON schedules an ongoing comparison between definitions and the current state of a directory. Every time a file is added, edited, or deleted from the monitored directory, the changes are tracked in snapshots.

When the drift definition is first set up, the current state of the resource can be compared against the last snapshot. This is a rolling snapshot. A specific snapshot can be selected as a baseline; this snapshot is pinned to the definition and then every subsequent change is compared against that snapshot. Pinning allows administrators to select a standard configuration. If it is pinned to a resource-level definition, the resource changes are compared to that. If a resource snapshot is pinned to a drift template, then changes for all resources of a type can be compared against the selected snapshot.

Finally, a new alert condition has been added to enable alerting, notifications, and responsiveness to drift on resources. Additionally, any drift changes show up on resources in the events timeline.

The JBoss ON remote API has been expanded to include a drift methods, so that drift configuration and monitoring can be automated.

Beginning in JBoss Operations Network 2.4, the server was able to deploy bundles. Bundles are complete application servers, configuration, packages, or patches which are installed on remote resources. Each bundle definition allows multiple versions and destinations, so it is easy to manage what versions are deployed on what resources. It is a simplified and flexible content delivery mechanism.

In JBoss ON 2.4, bundles could be deployed only to platform resources. In JBoss ON 3.0, the bundle system has been expanded so that bundles can be deployed to server resources along with platform resources. Resource plug-ins can now define a new <bundle-target> element, which sets a base directory or directories for the provisioning process to use. Of the default resources, three resource types support provisioning:

A local network may have several separate environments — development, staging, production — which all use similar resources and JBoss ON server settings. Server synchronization allows administrators to export configuration settings from one JBoss ON server, make any necessary edits, and import them into another JBoss ON server.

Two configuration areas can be synchronized:

When the configuration is exported, it is sent to an XML file. Administrators can edit the settings, if necessary. The JBoss ON server validates the file before importing it, which mitigates some risk on importing data.

Server synchronization is performed using the JBoss ON CLI. Example scripts are available as part of the JBoss ON installation in the installDir/rhq-remoting-cli-version#/samples/ directory. Documentation with usage examples is available in Configuring JBoss ON Servers and Agents.

JBoss ON has its own command-line client that can be used to manage server instances in the same way that the web UI manages servers. Much like running a script resource or launching an operation in response to an alert condition, a server CLI script can be run in response to an alert condition.

The JBoss ON script is added to a content repository as an available package. The script (JavaScript file) can then be selected when configuring an alert notification.

An example CLI alert script is included in the server files, in serverInstallDir/alert-scripts/.

Certain resource types (session beans and web servers) deliver call time or response time data. This information contains pre-aggregated measurements for the maximum, minimum, or average results for the responses.

Resources which collect call time data can use that pre-processed information as the basis for alert notifications, the same as other monitoring data. The call-time data condition can be set to issue an alert when it changes, increases, or decreases in value or when it crosses a defined threshold. It can also be filtered using regular expressions, so only certain measurements or values are considered as part of the condition.

Two types of resources support call-time data:

JBoss ON alert definitions have long supported both AND and OR operators. If a resource encountered one condition and then another, an alert would be issued. This allows administrators to get both detailed information and to create detailed responses through scripts and operations. For example, if a JBoss server had a high thread count and a low free memory, then administrators could run a particular script or start another JBoss resource.

However, while the AND operator was effective with different metrics, it could trigger unexpected alerts when it was used with the same metric in an attempt to create a range.

JBoss ON 3.0 introduces a new range condition, which triggers an alert only if a measurement is between two values.

Previously, any user with global inventory permissions could create and manage content repositories. This method had granted very broad access permissions, where a user had global access to the inventory in order to manage content.

JBoss Operations Network 3.0 defines a new access control scheme for repositories and the content within them. Every user has the ability to create repositories and to upload packages to them. Additionally, repositories have two new settings which control access to them:

JBoss Operations Network 3.0 also introduces a new access control permission, repositories. Any user with that permission can manage any configured repository, regardless of who the repository's owner is. Repositories without an owner can only be managed by users with the repositories permission. Lastly, only users with this permission can associated a content source with a repository; all other users must add packages manually.

As part of the upgrade process, all existing repositories are automatically assigned to be private with no owner. This restricts all access to the repositories to administrative users, which is similar to the behavior in JBoss ON 2.4. All users with the inventory permission are automatically assigned the repositories permission.

In previous versions of JBoss ON it was not possible to remove any agent resource plug-ins from the JBoss ON configuration. Now, agent plug-ins can be deleted (removed and blocked) or purged (removed and allowed to be reloaded) from the JBoss ON configuration.

PostgreSQL 9.0 can now be used as the backend database for the JBoss ON server.

JBoss ON 3.0 introduces a new resource plug-in for mod_cluster domains. This is for mod_cluster version 1.1.2^[1].

The mod_cluster plug-in will be one of the new standard resource plug-ins with JBoss ON.

For more information on how JBoss ON manages mod_cluster is in Manage JBoss Servers with JBoss ON.

JBoss ON 3.0 includes a JBoss AS 7.1 resource plug-in which adds early support for individual servers, host controllers, domain controllers, server groups, and managed servers.

This is included in a special Tech Preview Plug-in Pack. More information on the managed resources is in the Resource Reference.

In previous versions of JBoss ON, the Discovery Portlet was included in the Dashboard by default. This portlet is no longer configured in the default Dashboard, but it can still be added to the Dashboard.

The autodiscovery queue can also be viewed in the Inventory area of the GUI.

Several things that were deprecated in JBoss ON 2.4 are no longer supported in version 3.0 of JBoss Operations Network:

Additionally, this supported server platform is deprecated in JBoss ON 3.0:

Many new classes and methods have been added to the JBoss ON remote API to support new functionality, and some existing methods have changed.

The list of changes between 2.4 and 3.0 is available with the API at https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Operations_Network/3.1/html/API/index.html.

In previous versions of JBoss ON, both JBoss AS and JBoss EAP instances were identified in the UI as JBoss AS resources. Beginning in JBoss ON 3.0, EAP resources are identified as EAP rather than AS.

Bugzilla 536007

If the installer is not bound to 0.0.0.0 when setting up a server, then it does not set all of the required connection properties. Specifically, the installer does not set the java.rmi.server.hostname parameter to the real value, and it uses the default of 0.0.0.0. This parameter must be set to the real IP address of the server by manually editing the rhq-server.properties file.

Bugzilla 588381

Automatic upgrades of agents on Windows appear to fail. Two conditions must be true for automatic upgrade of agents to work on Windows:

Bugzilla 616979

When starting a server while agents are running, the server may log servlet errors in the logs. This is because the remoting (communications) classes are loaded early in the startup sequence, before the server is completely started. This causes some communications interruptions until the server is completely started. These errors can be ignored.

Bugzilla 617123

If a JBoss ON server was added to the resource inventory, the old JBoss ON server resource must be deleted from the inventory after upgrade. The old resource entry is unusable after upgrade.

Bugzilla 663610

Null pointer exceptions for the org.apache.catalina.connector.CoyoteAdapter service are returned when the JBoss ON 3.0 server is first installed. These errors are harmless and can be ignored. Installation will complete successfully, and both the server and the GUI will start and run properly.

Bugzilla 742486

The installer shows non-replaced {} properties.

Bugzilla 579766

The password mechanism in the server installer doesn't properly hash Unicode characters. The Unicode characters are translated into the HTML entities, and then the HTML characters are hashed and stored as the password.

For example, the string 你好 is treated as the string 你好 in the installer, and the second string is the one that is hashed and stored in the rhq-server.properties file.

After configuring the server, but before logging in, manually update the password in the rhq-server.properties file:

Bugzilla 828938

When a plug-in, effectively a resource type, is deleted, the agent's plug-in container is automatically rebooted, to reload the new configuration. If the agent itself is running as a daemon, then rebooting the plug-in container also kills the agent thread. That means that if a plug-in (with resources of that type in the inventory) is deleted while the agent is running in the background, the agent process is stopped.

The agent can be restarted without any errors, and the plug-in is successfully removed.

Bugzilla 675862

The agent assumes that PostgreSQL uses a default password. If a different password is used, the PostgreSQL resource is shown as unavailable in the UI even if it is running.

Bugzilla 749642

A dynagroup definition with a short recalculation interval (less than two minutes) can cause duplicate groups to be created.

Hot deployment fails if the file changes during provisioning.

If a bundle is being deployed in a hot deployment and one of the underlying bundle files, like a WAR or JAR, is changed while the bundle is being uploaded, then provisioning will fail.

Bugzilla 615978

Using the Recipe option to upload a recipe file separately than the bundle archive files requires that the XML in the recipe be well-formed and that all tags are explicitly closed, using the format <tag></tag>, not the abbreviated format <tag />.

Additionally, the Recipe option's upload button does not work on Internet Explorer. To add a recipe file using this option with Internet Explorer, copy the entire recipe file and paste it directly into the text box.

Manually added a package to a repository fails because it says the package already exists.

When adding a package to one repository through the UI, it may fail with an error claiming that the package already exists, even if the package isn't in the specified repository. This is because a package with the same name exists in another repository and it causes a collision in the database.

It is currently not possible to have the same package in two repositories or to move or share a package between repositories.

It is possible to work around this issue by using CLI scripts. The JBoss ON CLI scripts store the username of the person uploading the package in the package version data automatically. If a person has access to all of the packages one has uploaded, then it is possible to extrapolate which repository contains the package and then manage the package there.

Bugzilla 642674

The JBoss ON remote API cannot be used to connect to the JBoss ON server when the client is running inside an application server. For example, the remote API cannot be run from a client inside an EAP instance; it fails with errors like the following:

Caused by: java.lang.IllegalArgumentException: interface
org.rhq.enterprise.server.auth.SubjectManagerRemote is not visible from class
loader
at java.lang.reflect.Proxy.getProxyClass(Proxy.java:353)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
at
org.rhq.enterprise.client.RemoteClientProxy.getProcessor(RemoteClientProxy.java:69)

Problems with Sessions and Multiple Tabs

If there are multiple tabs open to the JBoss ON UI and one of those sessions times out, then the other tabs will register errors. This can also occur if multiple people are logged into JBoss ON as the same user.

Bugzilla 703856

Searching for a resource with a backslash (\) in the name returned no results, even if the resource exists.

Bugzilla 736732: Bookmarked UI Pages May Display the Old UI

The page names used for different pages in the JBoss ON UI for version 3.0 are different than the ones used in JBoss ON 2.4. However, because JBoss ON 3.0 retains some of the elements used in the older JSF-based UI, these pages still exist. This means that bookmarks will go to the old style pages.

For example, the Dashboard page in the old JSF UI had the URL http://localhost:7080/Dashboard.do/. In the new UI, the location is http://localhost:7080/coregui/#Dashboards.

All of the new pages have the coregui/ element in them. Remove any old bookmarks and replace them with the new GWT-based pages in the coregui/ area.

Bugzilla 741414

Alerts with compound AND conditions can incorrectly fire when one of the conditions goes from true to false within 30 seconds of the other condition going from from false to true.

Bugzilla 742804

Alert conditions and alert notifications in an alert definition cannot be edited. The condition or notification must be deleted and a new item added.

Bugzilla 755673

The path is required to be set for each includes or excludes item if a pattern is set. For example, to include only *.conf files, then the pattern is set to *.conf and to look within the base directory, the path must be set to a period (.), to indicate the current directory.

Bugzilla 758426

Drift monitoring is not supported for embedded web applications, only for standalone applications.

Bugzilla 760105

When looking at the carousel view, changing the filters can cause a globally uncaught exception in the UI. There are no errors in the agent or server logs.

Bugzilla 760145: Using a root directory on Windows corrupts the drift entry file paths

When a root directory, such as C:\ or D:\, is the base directory in the drift definition, the backslash ends up escaping the first character in the path. For example, C:\tmp shows as C:\mp. This makes all of the drift file paths for that definition wrong.

The best workaround is to use only non-root paths as the base directory for drift definitions on Windows.

Bugzilla 760289: Using a broad directory for the base directory can hang the agent

The drift detection process fetches all files, recursively, under the base directory to check for files that match the filters. (The drift process does not digest all the files, but it does check them.) This occurs even if there are Includes arguments that limit drift monitoring to only certain subdirectories.

If the base directory is set to a root or a broad directory directory, then effectively the agent scans the entire filesystem to check for matching files. The agent could hang or have very poor performance.

One indicator of this problem is if the initial snapshot for a definition takes a very long time to appear.

To work around this, use multiple drift definitions that set the base directory to the given subdirectory. (The path can be set to a period (.) to look for patterns only in the local base directory.)

Instead of this definition:

Definition
base directory: C:\
Includes: myDir1
Includes: myDir2

Create two definitions:

Definition 1
base directory: C:\myDir1

Definition 2
base directory: C:\myDir2

Bugzilla 761320: Default drift detection and interval settings can prevent drift detection from running

The default interval setting for a drift definition is 30 minutes, meaning that the drift is scheduled to run 30 minutes after the end of its last drift detection run. By default, the agent runs a detection scan every minute.

The problem is that this can result in the definition schedule getting pushed out, so that the detection scan never runs for that definition. For example, the agent runs a scan for Definition A at 12:00 and grabs the initial snapshot. The scan ends at 12:01. The next scheduled detection run for Definition A is 12:31, and the next detection scan for the agent is 12:02. When the agent detection scan runs at 12:02, it skips Definition A because it sees that the next interval for Definition A is 12:31 — however, the agent still updates the scan time for Definition A. This bumps the next interval for Definition A to 12:32. When the next agent scan runs at 12:03, it again skips Definition A, but bumps its timestamp, which bumps the schedule another minute.

A patch for this problem is available https://access.redhat.com/jbossnetwork/restricted/softwareDetail.html?softwareId=10113.

Alternatively, work around this situation by setting the rhq.agent.plugins.drift-detection.period-secs value higher than the highest drift definition. (It may be feasible to set the drift definition intervals lower to allow a moderate drift detection scan period.) For example, to set the interval to 15 minutes (900 seconds):

agentRoot/rhq-agent/bin/rhq-agent.sh -Drhq.agent.plugins.drift-detection.period-secs=900

Bugzilla 671496 and Bugzilla 671500

If EAR, WAR, or script resources are deleted, the agent throws an exception during discovery, and the server is not informed that the resource was deleted.

Bugzilla 696151

Apache directives are case-insensitive, but the Apache plug-in treats them as if they were case-sensitive. This makes the plug-in disregard directives with non-default case.

Bugzilla 699870

Discovering a JBoss AS instance fails if the configuration directory is a URL.

Bugzilla 699893

The discovery process fails to determine the JNP URL if the data directory is not located at ${jboss.server.home.dir}/data.

Bugzilla 701092

Turning off an agent does not show the platform as unavailable for 15 minutes, the time of the next agent availability report.

Bugzilla 731101

Shutting down a JBoss AS 5 resource can fail with java.rmi.NoSuchObjectException: no such object in table.

Bugzilla 734141

It is not possible to add some system properties for a JBoss AS resource.

Bugzilla 758503

Some JBoss AS 5 plug-in resources have unset read-only configuration properties, which means the values have to be re-entered every time the configuration is viewed.

Bugzilla 674567

Using a case-insensitive login with LDAP authentication fails and opens a blank page.

Bugzilla 738209

A role cannot be deleted if an LDAP group is assigned as a member.

Bugzilla 734527

Attempting to update the members in a compatible group with thousands of members times out and fails with 'Failed to fetch Resource Group.'

Bugzilla 737193, Bugzilla 737190, Bugzilla 738799

Viewing configuration, alerts, or other data for groups with more than 1000 members can fail with the SQL exception maximum number of expressions in a list is 1000.