All Classes and Interfaces
Class
Description
REST representation of a delta between two campaigns' candidate sets.
REST representation of one grouped failure of a campaign: the failure message
code the console localizes, how many items carry it, and whether a retry would
re-attempt them — the SERVER's answer to that last question, so the console
never holds its own copy of the retryable rule.
REST representation of a cleanup campaign item.
REST representation of a cleanup campaign.
REST representation of a dry run's per-UNIT progress: how many subtrees settled,
how deep the retries went, and which ones are in flight.
REST representation of ONE scan unit in flight: the subtree a reader is walking,
its own resume checkpoint and its own counts.
Action planned by a cleanup campaign on a candidate file.
One per-item failure of a bulk keep / un-keep: the item that could not be
decided and the message code explaining why.
Outcome of a bulk keep / un-keep: how many items were decided, and which ones
failed with which reason.
Domain model of a cleanup campaign.
Item aggregates of one campaign (candidate count/bytes, reclaimed bytes,
item-rows existence), computed by a single grouped query for a whole
campaigns list instead of per-campaign aggregate queries.
Domain model of a cleanup campaign item (one candidate file and its
lifecycle).
Single authority over campaign state transitions and their side effects: the
allowed-transitions guard, persisting the new state, the WebSocket
stateChanged event, and registering/unregistering the JCR freshness
observation listener on entry/exit of PUBLISHED.
Cleanup campaigns lifecycle: dry-run launch, publication (single active
campaign platform-wide), grace-deadline locking, execution trigger,
cancellation, user exemptions ('keep'/'un-keep'), candidate freshness
refresh, campaign comparison, report retention and CSV archiving.
Lifecycle states of a cleanup campaign.
RDBMS storage of cleanup campaigns and their items: the only layer touching
the cleanup DAOs, mapping entities to simple domain models.
Aggregates of a cleanup campaign snapshotted at completion into its
summaryJson.
A file (JCR nt:file node) qualifying for a cleanup action, as computed by a
dry-run scan or a revalidation.
Delta between two campaigns' candidate sets, matched by node uuid.
One bucket of a campaign comparison (persisting / new / gone): the item count
and reclaimable-bytes sum computed by a single set-based aggregate query.
Single definition of the physical drive layout swept by cleanup campaigns
(scan roots, drive-root depths) and of the cleanup-wide static constants.
Pure, JCR-free evaluation of the cleanup candidate criterion:
a node under an excluded path prefix is never a candidate
DELETE: created AND last modified older than the campaign period, and
content size above the floor
PURGE_VERSIONS: the file owns at least one PURGEABLE version — see
CleanupCriterionEvaluator.selectVersionsToRemove(java.util.Map<java.lang.String, java.lang.Long>, java.lang.String, java.lang.String, org.exoplatform.addons.documents.cleanup.model.CleanupParams, long) for the union of the age rule and the count
rule that defines the removal set — and the size of that removal set is above
the floor
An exemption (exo:cleanupExemption mixin) is deliberately NOT evaluated here:
an exempted node still qualifying by these criteria is emitted as an
exempted-flagged
CleanupCandidate, so it stays
visible as 'Kept' in every campaign.Domain model to REST DTO mapping.
Single definition of the throughput ETA of a cleanup worker, shared by the
dry-run scan and the execution purge — the two workers used to carry the very
same arithmetic verbatim, so a change (or a regression) in one of them silently
diverged from the other.
Asynchronous batched purge of a LOCKED campaign, under a JCR system session.
Outcome of an exemption mixin change (add or remove) on a JCR node, letting
the Service layer distinguish a node that no longer exists (item GONE) from a
transient write failure (item state untouched, retryable).
One group of a campaign's failed items: the failure message code and how many
SKIPPED items carry it, computed by a single grouped aggregate query (the item
rows are never loaded).
Scheduled glue, no business logic: flips the PUBLISHED campaign to LOCKED
once its grace deadline elapsed, enforces report retention, and watchdogs the
scan/purge workers (a campaign whose worker thread died mid-run is resumed on
the next tick, without a JVM restart).
Single definition of the owner display name of a cleanup item, shared by the
REST DTO builder and the CSV report so the exported name and the one shown in
the UI can never disagree.
State of a single campaign item (candidate file).
JCR observation listener registered only while a cleanup campaign is
PUBLISHED.
JCR implementation of
CleanupJcrStorage against the collaboration
workspace, always through a system session (async cleanup workers carry no
user conversation state).Receives the scanned batches streamed by
CleanupJcrStorage.scanRoot(String, String, int, CleanupParams, ScanBatchConsumer).Nodes a scan batch could not EVALUATE, and the first failure that did it.
Parameters of a cleanup campaign.
Outcome of a purge operation (hard delete or versions purge) on one item.
Result of re-evaluating a former candidate against the campaign criteria,
distinguishing a node that disappeared, one that got exempted, one that no
longer qualifies, one still qualifying (candidate != null), and an outcome
that could NOT be computed (transient JCR read failure): an unknown outcome
must never be mistaken for a spared/gone node — the execution skips the item
(never deletes on doubt) and the freshness refresh leaves it untouched.
Single definition of the revalidation-outcome to item-state mapping, shared
by the freshness refresh (observation glue) and the execution-time
revalidation so both stay strictly identical.
Asynchronous dry-run scan of the collaboration workspace, PARALLELISED over
scan UNITS: the tree is partitioned once (see
CleanupConstants.SPLIT_SCAN_ROOTS), several reader threads walk their
own unit each, and ONE writer thread persists everything they stream through a
bounded queue.One partition of the dry-run scan: the JCR subtree ONE reader thread walks,
with its own state, its own path checkpoint and its own counters.
Per-UNIT breakdown of a campaign's dry run: the state counts, the deepest
attempt any unit has spent, and the units currently in flight.
State of a single dry-run scan unit (a partition of the scanned tree walked by
ONE reader thread).
RDBMS storage of the dry-run scan units: the only layer touching the scan-unit
DAO, mapping entities to simple domain models.
Cleanup campaign settings: platform defaults overridable via exo.properties
and persisted overrides in
SettingService (GLOBAL context).The ONE definition of what an item's action reclaims, in Java.
Renders a purge failure into the compact diagnostic persisted in the item's
FAILURE_DETAIL column — never a full
printStackTrace.Per-user summary of the currently relevant campaign: their candidates and
kept files during the grace period, their outcome once completed.
Push-only CometD channel notifying connected administrators of campaign
progress and state changes.
Flat WebSocket payload pushed to administrators while a campaign scan or
execution progresses.
Bulk keep request body: {"itemIds": [...]}.
REST representation of a bulk keep / un-keep outcome: the UI needs the
per-item failures to warn instead of reporting a success when nothing was
actually kept.
REST representation of the per-user summary of the currently relevant
campaign.
Paged REST wrapper: {items, page, size, totalItems}.
Partial-update request body: {"name": "..."} and/or {"graceDays": N}.