00.74.20

Release date: 2026-06-23 Previous release: 00.74.10 Maven coordinates (parent): com.svenruppert.jsentinel:jSentinel-parent:00.74.20 Full changelog: GitHub release v00.74.20

A tens-release that closes the 00.74-era feedback gap on app-side persistence and folds the three 00.74.10 cleanup items. It introduces no new security primitive and no new module — the new types live in the existing jSentinel-persistence-eclipsestore.

Headline — JSentinelStorageFactory + JSentinelStoragePair

Before 00.74.20, an app that wanted both the framework storage (audit, sessions, …) and its own Eclipse-Store domain data had to run two EmbeddedStorageManagers with two independent shutdown hooks — undefined ordering, no addSuppressed. Now one factory opens both under a single parent directory with one two-phase shutdown:

try (JSentinelStoragePair pair = JSentinelStorageFactory.openAt(Path.of("data"))) {
  VaadinSecurity.bootstrap()
      .audit(a    -> a.storeBacked(pair.framework().auditEventStore()))
      .sessions(s -> s.storeBacked(pair.framework().sessionStore()))
      .install();
  // pair.app() is your domain-data manager.
  // pair.close() runs two-phase: app first, framework second — the
  // framework close ALWAYS runs, even if the app shutdown throws.
}

New public API (jSentinel-persistence-eclipsestore)

• StorageLayout(frameworkSubdir, appSubdir) — sub-directory names under the pair’s parent (DEFAULT = ("jsentinel-store", "app-store")); the compact constructor rejects null / blank / path-separator / NUL bytes and same-subdir collisions.
• JSentinelStoragePair — a record implementing AutoCloseable; two-phase close() with addSuppressed discipline and an idempotency guard (double-close is a logged no-op).
• JSentinelStorageFactory.openAt(Path parent) / openAt(Path parent, StorageLayout layout) — validates the parent directory and rolls back any half-opened manager on failure.

All four types ship @ExperimentalJSentinelApi until 00.75 confirms the shape. The existing EclipseStoreJSentinelStorage.openAt(Path) keeps its 00.70 public surface unchanged.

What it does not do

No atomic cross-store transaction, no .storage(...) bootstrap sub-builder (earliest 00.75), no multi-tenant separation, no encryption-at-rest — Eclipse Store’s own file layout, no extras.

00.74.10 cleanup, folded in

• HealthView admin demo — a Vaadin admin view (@RequiresPermission("admin:roles")) rendering runtime.summary(), health badges and prettified runtime.toJson(), refreshed via the new accessor.
• JSentinelBootstrapInitListener.currentRuntime() — a static accessor for the active JSentinelRuntime, so runtime swaps stay visible.
• Coordinated demo-pom bump — the ten demo-jsentinel-* modules stepped from 00.73.00 to the 00.74.20 line (the skew that had blocked the HealthView demo at 00.74.10).

The three persistence skills and their demos (jsentinel-vaadin / rest / standalone-persistence) migrate to the pair factory and drop the old two-manager pattern.

Security hygiene

• bcprov-jdk18on 1.78.1 → 1.84 — closes two Dependabot alerts on the 00.74.10 line (LDAP-injection in LDAPStoreHelper; a timing channel in FrodoEngine). Neither code path is used by jSentinel-crypto-bc (only the low-level Argon2id / bcrypt / scrypt primitives), so the real exploit surface against jSentinel deployments is zero — the bump is precautionary.
• Javadoc-jar regression fixed — jsentinel.css moved to a tracked path plus a bundle guard that fails the build if any -javadoc.jar is under 50 KB, so published javadoc jars are non-empty again.

Quality

Every other module is unchanged from its prior score by construction. Test discipline unchanged: no mocks (a reactor-wide Maven Enforcer ban keeps Mockito / EasyMock / PowerMock / byte-buddy-agent out).

Migration

None. The Storage-Pair is an opt-in addition with its own factory entry point; existing code keeps working. Just bump the version to 00.74.20.