What’s New in OpenNMS Horizon 36

System requirements and Dependencies

  • Java 21: OpenNMS Horizon requires JDK 21.

  • PostgreSQL 14 or higher: This version of OpenNMS Horizon requires a supported version of PostgreSQL.

New features and important changes

Spring, Hibernate, and Camel platform upgrade

The core application frameworks have been upgraded to currently supported versions: Spring Framework 5.3, Spring Security 5.8, Hibernate 5.6, Hibernate Validator 6.2, and Apache Camel 3.22. The OpenNMS-patched forks of Spring, Spring Security, and Hibernate have been removed in favor of stock releases, and Eclipse Gemini Blueprint has been replaced by an OpenNMS Spring OSGi extender.

Most installations require no action, but there are behavior and compatibility changes for installations with custom Spring Security configuration (SSO, LDAP), custom Camel routes, or plugins that use the OpenNMS persistence APIs. See Spring, Hibernate, and Camel Platform Upgrade for details.

Spring, Hibernate, and Camel platform upgrade

The core application frameworks have been upgraded to currently supported versions: Spring Framework 5.3, Spring Security 5.8, Hibernate 5.6, Hibernate Validator 6.2, and Apache Camel 3.22. The OpenNMS-patched forks of Spring, Spring Security, and Hibernate have been removed in favor of stock releases, and Eclipse Gemini Blueprint has been replaced by an OpenNMS Spring OSGi extender.

Most installations require no action, but there are behavior and compatibility changes for installations with custom Spring Security configuration (SSO, LDAP), custom Camel routes, or plugins that use the OpenNMS persistence APIs. See Spring, Hibernate, and Camel Platform Upgrade for details.

SNMP datacollection config moved to DB with new UI

The contents of etc/datacollection-config.xml and etc/datacollection/*.xml are migrated into the database during the upgrade process, and the original files are moved to etc_archive/. After upgrade, manage SNMP data collection through the *Administration → Manage SNMP Data Collection Config* page (or the REST API under /api/v2/datacollectionconf). Direct edits to the archived XML files no longer take effect.

Snmp Config file snmp-config.xml moved to DB with new UI

The contents of snmp-config.xml are migrated into the database during the upgrade process, and the original file is moved to etc_archive/.

After upgrade, manage SNMP configuration through the Integrations → SNMP Agent Configuration page (or the REST v2 API under /api/v2/snmp-config). Direct edits to the archived XML file no longer take effect.

The new UI supports definition lookup by IP address and location, profile management, and supports both IPv4 and IPv6.

The legacy file-based SNMP credential encryption feature (the org.opennms.snmp.encryption.enabled property and the snmp-config-encrypt / snmp-config-decrypt Karaf commands) has been removed. The upgrade handles existing encrypted configurations automatically. For protecting SNMP credentials, use Secure Credentials Vault (SCV) metadata expressions in your SNMP configuration.

See SNMP Configuration REST API for details.

Trapd Config file trapd-configuration.xml moved to DB with new UI

The contents of trapd-configuration.xml are migrated into the database during the upgrade process, and the original file is moved to etc_archive/.

After upgrade, manage trapd configuration through the Integrations → Trap Configuration page (or the REST v2 API under /api/v2/trapd). Direct edits to the archived XML file no longer take effect.

See Trapd REST API (v2) for details.

Environment variable support in service configuration

Individual services in service-configuration.xml can now be enabled or disabled at runtime via environment variables, using the pattern CORE_SERVICE_<NAME>_ENABLED. For example, set CORE_SERVICE_TELEMETRYD_ENABLED=false to disable Telemetryd without editing the configuration file.

This is particularly useful for containerized deployments where service composition is controlled via environment. Existing enabled="true|false" values in the file remain the default when no environment variable is set.

The Manager and Eventd services must always be enabled and cannot be disabled via environment variable.

Ticketing plugin is now automatic

The OSGiBasedTicketerPlugin is now the default ticketer plugin. Ticketing is automatically enabled when an OSGi-based ticketer plugin is installed and disabled when it is removed. The NullTicketerPlugin and the opennms.ticketer.plugin property have been removed.

If you have opennms.ticketer.plugin=org.opennms.netmgt.ticketd.NullTicketerPlugin in a custom properties file under etc/opennms.properties.d/, remove that entry before upgrading. If you previously set opennms.ticketer.plugin=org.opennms.netmgt.ticketd.OSGiBasedTicketerPlugin, that entry is now redundant and can be removed. The opennms.alarmTroubleTicketEnabled property is no longer required but can still be used to explicitly enable or disable ticketing.

Light and dark mode for the Vue UI

The Vue-based web UI now supports a light/dark theme toggle, in addition to the system-default option.

File eventconf.xml moved to DB

The contents of the file eventconf.xml will be stored in the database during the upgrade process and all files in etc/events will be moved to etc_archive. These events will not be imported into the database.

After upgrade, manage event configurations through the Administration → Manage Event Configurations page (or the REST API under /api/v2/eventconf).

See Migrating event files after upgrade for the steps to re-upload your customized event files from etc_archive/events/.

Breaking changes

Jakarta Mail migration and OAuth2 (XOAUTH2) SMTP support

All mail sending and reading now uses Jakarta Mail 2.1 (Eclipse Angus) instead of JavaMail 1.4; existing javamail-configuration.xml and javamail-configuration.properties files load unchanged. The JMTA local-MTA transport is gone (use-jmta is still accepted, but mail is sent over SMTP to the configured mail host), <javamail-property> entries now reach the mail session instead of being ignored, and SSL/TLS connections now verify that the server certificate covers the mail host. See Mail server TLS for the TLS properties, and token authentication for the OAuth2 (XOAUTH2) SMTP authentication that Microsoft 365 and Gmail now require.

Scripted (BSF) notifications now run on JSR-223

BSFNotificationStrategy executes scripts through the Java scripting API instead of the retired Apache Bean Scripting Framework; existing scripts generally keep working, but see Scripted Notifications for the deprecated parameters and behavior changes.

Slack and Mattermost notification strategies replaced by a webhook strategy

SlackNotificationStrategy and MattermostNotificationStrategy have been removed in favor of WebhookNotificationStrategy, which takes the URL, method, headers, and body from the notification command and so can also target Microsoft Teams, Discord, and non-chat endpoints. The org.opennms.netmgt.notifd.slack. and org.opennms.netmgt.notifd.mattermost. properties no longer have any effect.

Neither strategy shipped as a stock notification command, so this affects only hand-added commands, which fail when a notice is sent until their <execute> element and arguments are updated. See Webhook Notifications for the mapping.

XMPP (Jabber) notification strategies removed

The XMPP notification strategies have been removed and xmpp-configuration.properties is ignored. Existing users.xml files with xmppAddress contacts still load, but no notifications are sent to them.

IRCcat notification strategy removed

The IRCcat notification strategy, the stock ircCat notification command, and the irccat.host and irccat.port system properties have been removed. An ircCat command left in an existing notificationCommands.xml still loads, but notices routed to it fail when sent.

Asterisk notification strategy removed

The Asterisk notification strategy, the AsteriskGateway daemon, the stock callHomePhone, callMobilePhone, and callWorkPhone notification commands, and the asterisk-configuration.properties and ami-config.xml files have been removed. Those commands left in an existing notificationCommands.xml still load, but notices routed to them fail when sent.

SAML and OpenID SSO support removed

Spring Security 5.8 has no compatible SAML/OpenID extension libraries, so they are no longer shipped. If single sign-on is enabled through a custom spring-security.d/.xml file, the web application fails to start after the upgrade — this affects *all logins, not just SSO. See Spring, Hibernate, and Camel Platform Upgrade for this and other upgrade-related compatibility changes.

WMI integration removed

The WMI monitor, detector and collector had been removed, as the WS-Man integration offers better support for newer versions of the Windows operating system.

JoeSNMP removed

The SNMP implementation JoeSNMP was removed in OpenNMS Horizon.

C3P0 connection pool removed

The C3P0 connection pool factory (org.opennms.core.db.C3P0ConnectionFactory) and etc/c3p0.properties have been removed. HikariCP is now the only supported pool, and has been the default since OpenNMS Horizon 35.

If your opennms-datasources.xml explicitly sets factory="org.opennms.core.db.C3P0ConnectionFactory", remove that attribute before upgrading.

At least PostgreSQL 14.0 is required

OpenNMS Horizon now requires PostgreSQL 14.x or newer. If you are running an older version, you must upgrade to PostgreSQL 14 or later. Attempting a schema upgrade with install -dis will result in an error. If upgrading PostgreSQL to at least version 14 isn’t possible and you’re completely blocked, the -Q flag lets you skip the version check. Use this only as a last resort, since it may affect compatibility. Be aware that doing so takes you beyond supported configurations — here be dragons.

Prometheus RemoteWrite plugin (formerly Cortex TSS plugin)

The OpenNMS Cortex TSS plugin has been renamed to the Prometheus RemoteWrite plugin to reflect that it works with any Prometheus remote_write-compatible time series store, not just Cortex. As part of the rename, the OSGi configuration PID changed from org.opennms.plugins.tss.cortex to org.opennms.plugins.tss.prometheus.

If you previously configured the plugin via ${OPENNMS_HOME}/etc/org.opennms.plugins.tss.cortex.cfg, rename the file to ${OPENNMS_HOME}/etc/org.opennms.plugins.tss.prometheus.cfg after upgrading. If you do not, the plugin falls back to default values and writes will not reach your configured time series store.

The Karaf feature is now opennms-plugins-prometheus-remotewrite (previously opennms-plugins-cortex-tss), and the KAR file is opennms-prometheus-remotewrite-plugin (previously opennms-cortex-tss-plugin). See the Prometheus RemoteWrite plugin documentation for details.

Jasper Reports engine

We have updated the Jasper Reports engine to version 7.0.7. Custom reports created using version 6.x must be updated to work with the new version.

Ops Board and Wallboard removed

The Vaadin-based Ops Board (operator board) and Wallboard, their dashlets, and the Wallboard Configuration admin page have been removed. These provided auto-rotating, dashlet-composed displays intended for wall-mounted operations screens.

The Ops Board and Wallboard main-menu entries and the admin/wallboardConfig.jsp page no longer exist, and any existing Ops Board configuration is no longer used. There is no drop-in replacement.

KSC Reports renamed to Graph Collections

The feature formerly labeled KSC Reports is now Graph Collections throughout the web UI (the main-menu entry, page titles, breadcrumbs, the Add to Graph Collection dialog, and the home-page section) and the documentation. The global search category formerly named KSC Report is now Graph Collection.

This is a user-facing label change only. The underlying configuration file (etc/ksc-performance-reports.xml), the REST endpoints under /rest/ksc, the KSC/*.jsp page URLs, and the internal identifiers are unchanged, so existing reports, saved bookmarks, and API integrations continue to work without modification.

Update any of your own documentation, runbooks, training material, or UI automation that refers to KSC Reports by name — including tests that match on the old menu label or the KSC Report search category — to use Graph Collections.

BeanShell integration deprecated

The last release of the BeanShell interpreter was in 2016. As such, we are deprecating support for BeanShell and will remove it in Horizon 37. Groovy support remains available everywhere BeanShell was implemented.