[OpenNMS/opennms] 8860e0: NMS-20236: use mchange-commons-java version 0.6.1

  Branch: refs/heads/merge-foundation/foundation-2023-to-foundation-2024
  Home:   https://github.com/OpenNMS/opennms
  Commit: 8860e08a486786ee0c926225d8bab38ce51b3e20
      https://github.com/OpenNMS/opennms/commit/8860e08a486786ee0c926225d8bab38ce51b3e20
  Author: Christian Pape <[email protected]>
  Date:   2026-08-25 (Tue, 25 Aug 2026)

  Changed paths:
    M core/db/pom.xml
    M dependencies/quartz/pom.xml

  Log Message:
  -----------
  NMS-20236: use mchange-commons-java version 0.6.1


  Commit: b9ad63b5948e9e4df47a3ba40bc2cbb3f2b177fe
      https://github.com/OpenNMS/opennms/commit/b9ad63b5948e9e4df47a3ba40bc2cbb3f2b177fe
  Author: Marshall Massengill <[email protected]>
  Date:   2026-08-26 (Wed, 26 Aug 2026)

  Changed paths:
    M opennms-config/src/main/java/org/opennms/netmgt/config/EventTranslatorConfigFactory.java
    A opennms-config/src/test/java/org/opennms/netmgt/config/EventTranslatorConfigReloadTest.java

  Log Message:
  -----------
  NMS-20258: Keep the DataSource across an event translator config reload (#8814)

EventTranslatorConfigFactory.update() unmarshalled the new configuration
through an overload that passed a null DataSource, so m_dbConnFactory was
cleared on every reload. SqlValueSpec reads that field when it evaluates,
so after the first reloadDaemonConfig for the Translator every mapping
holding a type="sql" value threw

  NullPointerException: Cannot invoke "javax.sql.DataSource.getConnection()"
  because "this.m_db" is null

and stopped translating until OpenNMS was restarted. Mappings without a sql
value kept working, which is why the reload looked successful.

update() was the only caller of the single-argument overload, so it now
passes the DataSource it already holds and the overload is gone.

Reproduced on a live 36.0.4 instance against a translation whose values are
resolved in sql. The shipped translator-configuration.xml resolves ifDescr,
ifName and ifAlias that way, so a reload leaves the default link-down and
link-up translations broken. Present unchanged since 2012 and on every
maintained branch.


  Commit: 334c627d758f9be390e459993e94b790fcf4726a
      https://github.com/OpenNMS/opennms/commit/334c627d758f9be390e459993e94b790fcf4726a
  Author: Marshall Massengill <[email protected]>
  Date:   2026-08-27 (Thu, 27 Aug 2026)

  Changed paths:
    M opennms-services/src/main/java/org/opennms/netmgt/collectd/CollectableService.java
    M opennms-services/src/test/java/org/opennms/netmgt/collectd/CollectableServiceTest.java
    M opennms-services/src/test/java/org/opennms/netmgt/collectd/CollectdIT.java
    M opennms-services/src/test/java/org/opennms/netmgt/collectd/ThresholdIT.java

  Log Message:
  -----------
  NMS-19979: clear data collection alarms after a restart or collectd reload (#8774)

* NMS-19979: clear data collection alarms after a restart or collectd reload

A dataCollectionFailed alarm never cleared if collection recovered across an
OpenNMS restart or a collectd configuration reload.

CollectableService keeps the last collection status in memory and updateStatus()
only emits an event on a transition. That status was seeded to SUCCEEDED, and
both a restart and rebuildScheduler() discard and rebuild every
CollectableService, so the recovery was no longer a transition, no
dataCollectionSucceeded was sent, and the alarm was orphaned.

Seed it to UNKNOWN instead. The first collection then always transitions,
whichever way it goes: a success emits dataCollectionSucceeded and clears the
alarm the previous generation left behind, and a failure emits
dataCollectionFailed exactly as before. Subsequent collections are unchanged,
so this costs one extra event per collected service per restart or reload, not
one per collection cycle.

An unmatched dataCollectionSucceeded creates a Normal severity alarm of its own,
which the default alarmd cleanUp rule deletes after five minutes.

* NMS-19979: Update collectd tests for the first-collection succeeded event

Seeding m_status to UNKNOWN makes the first successful collection of every
scheduling generation a transition, so it now emits dataCollectionSucceeded.
Two existing tests assumed that event never fired.

ThresholdIT anticipates it once per generation. A nodeCategoryMembershipChanged
event unschedules and reschedules the node, building a fresh CollectableService,
so the reschedule reports success again after the second category change.

CollectdIT.testOneMatchingSpec performs real collections, so it accounts for the
send explicitly rather than loosening tearDown's verifyNoMoreInteractions.


  Commit: 2f1830148cb2b86a3e63e58b8684dcd5d8f70ef0
      https://github.com/OpenNMS/opennms/commit/2f1830148cb2b86a3e63e58b8684dcd5d8f70ef0
  Author: Christian Pape <[email protected]>
  Date:   2026-09-01 (Tue, 01 Sep 2026)

  Changed paths:
    M pom.xml

  Log Message:
  -----------
  NMS-20251: bumped netty version


  Commit: 540e5118303a7e305fb3b7cd13f39c6ef81f9c90
      https://github.com/OpenNMS/opennms/commit/540e5118303a7e305fb3b7cd13f39c6ef81f9c90
  Author: Morteza E <[email protected]>
  Date:   2026-09-01 (Tue, 01 Sep 2026)

  Changed paths:
    M pom.xml

  Log Message:
  -----------
  Merge remote-tracking branch 'origin/foundation-2023' into foundation-2024


Compare: https://github.com/OpenNMS/opennms/compare/2e76241023e7...540e5118303a

To unsubscribe from these emails, change your notification settings at https://github.com/OpenNMS/opennms/settings/notifications


_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/wiki/index.php?page=MailingListFaq
opennms-cvs mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-cvs