Fix SCR deadlock in SecurityManager by making repoService a dynamic reference

[Copilot]

On startup, SecurityManager (immediate=true) could deadlock with RepositoryService activation: Felix SCR held the component state lock while binding the static mandatory @Reference, which contended with RepositoryService's own factory lock in another thread. This surfaced as SEVERE: FrameworkEvent ERROR … Service factory exception: Could not obtain lock, failing CI log checks.

Changes

• SecurityManager.java — change repoService from a static to a dynamic reference:

// Before
@Reference
protected RepositoryService repoService;

// After
@Reference(policy = ReferencePolicy.DYNAMIC)
protected volatile RepositoryService repoService;

With ReferencePolicy.DYNAMIC, Felix SCR no longer holds the component state lock during bind/unbind, eliminating the lock contention. volatile is required by OSGi spec for JMM visibility on dynamic field references. The field is only consumed during @Activate (passed by value into provider constructors), so there are no functional regressions.

Original prompt

Problem

During startup, SecurityManager (declared immediate = true) holds the Apache Felix SCR component state lock while trying to bind its mandatory static @Reference to RepositoryService. If RepositoryService is still being activated in another thread (also holding its own SCR lock), a classic deadlock occurs:

SecurityManager (immediate=true, holds SCR lock)
  └─ needs RepositoryService (factory locked by its own activation thread)
       └─ deadlock → ServiceException: Could not obtain lock

This manifests in the startup log as:

SEVERE: Bundle: org.openidentityplatform.openidm.security [149] FrameworkEvent ERROR
org.osgi.framework.ServiceException: Service factory exception: Could not obtain lock
    at org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:354)

These SEVERE log lines cause the CI workflow (build.yml) checks to fail:

! grep "SEVERE" openidm/logs/openidm0.log.0

Fix

In openidm-security/src/main/java/org/forgerock/openidm/security/SecurityManager.java:

1. Add the import for ReferencePolicy:

import org.osgi.service.component.annotations.ReferencePolicy;

2. Change the repoService field from a static to a dynamic reference and add volatile:

Before:

@Reference
protected RepositoryService repoService;

After:

@Reference(policy = ReferencePolicy.DYNAMIC)
protected volatile RepositoryService repoService;

Why this works

With ReferencePolicy.DYNAMIC, Felix SCR does not hold the component state lock when binding/unbinding the service, eliminating the lock contention deadlock. The volatile keyword is required by the OSGi spec for dynamic references to ensure JMM visibility.

The repoService reference is passed by value into the resource provider constructors inside @Activate, so those providers retain a valid reference regardless of later bind/unbind cycles on the field. There are no functional regressions.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Please find a solution for this failing job. Use the logs, job definition, and any referenced files where the failure occurred. Keep your response focused on the solution and include code suggestions when appropriate.

Assistant: Sure! Let me fetch the logs for that job right away.

Assistant: ## Root Cause

The job fails at the "Start OpenIDM" step (line 139–140) in the ui-smoke-tests job (running with samples/workflow). OpenIDM does start successfully ("OpenIDM ready" is found), but then the strict log checks fail because of these non-fatal OSGi FrameworkEvent ERROR entries:

SEVERE: Bundle: org.openidentityplatform.openidm.security [149] FrameworkEvent ERROR
SEVERE: Bundle: org.openidentityplatform.openidm.util [175] FrameworkEvent ERROR

These are known transient OSGi lifecycle events related to a service lock contention in org.forgerock.openidm.security during startup. They don't prevent OpenIDM from becoming ready and are not true application errors.

The same strict checks also exist in the build-maven "Test on Unix" step at lines 58–59.

---

Fix

Filter out the known benign FrameworkEvent ERROR lines from both checks in both steps:

ui-smoke-tests — "Start OpenIDM" step (lines 139–140)

          ! grep "ERROR"  openidm/logs/openidm0.log.0 | grep -v "FrameworkEvent ERROR"
          ! grep "SEVERE" openidm/logs/openidm0.log.0 | grep -v "FrameworkEvent ERROR"

build-maven — "Test on Unix" step (lines 58–59)

          ! grep "ERROR"  openidm/logs/openidm0.log.0 | grep -v "FrameworkEvent ERROR"
          ! grep "SEVERE" openidm/logs/openidm0.log.0 | grep -v "FrameworkEvent ERROR"

How it works

• grep "SEVERE" openidm/logs/openidm0.log.0 | grep -v "FrameworkEvent ERROR" — filters out the known benign OSGi framework event lines, leaving only genuine SEVERE messages.
• ! (pipeline) — the exit code of the pipeline is the last command's exit code (grep -v). If no lines remain (all were benign), grep -v exits 1, negated to 0 ✅. If real SEVERE lines remain, grep -v exits 0, negated to 1 ❌.

This preserves the intent of the checks (catching real errors) while ignoring the known non-fatal OSGi FrameworkEvent ERROR noise from the security and util bundles.

User: ```
2026-05-06 15:19:20:880 WARNI Bundle: org.openidentityplatform.openidm.security [149] bundle org.openidentityplatform.openidm.security:7.0.3.SNAPSHOT (149)[org.forgerock.openidm.security(17)] : Could not get service from ref [org.forgerock.openidm.repo.RepositoryService, org.forgerock.json.resource....

This pull request was created from Copilot chat.