Timothee Maret created SLING-12687:
--------------------------------------
Summary: Introduce a JournalDistributionPackageBuilder
Key: SLING-12687
URL: https://issues.apache.org/jira/browse/SLING-12687
Project: Sling
Issue Type: Improvement
Components: Content Distribution
Affects Versions: Content Distribution Journal Core 0.4.0
Reporter: Timothee Maret
Fix For: Content Distribution Journal Core 0.5.2
Sling Journal based Content Distribution does not leverage the
DistributionPackageBuilder as intended by the Sling Content Distribution
design. Because the request context (paths, request type) is not persisted in
the FileVault packages, it is impossible to build and return
[DistributionPackage|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/DistributionPackage.java]
as required by the
[DistributionPackageBuilder|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/packaging/DistributionPackageBuilder.java]
interface.
So far we have worked around that limitation by specializing the handling per
request type above the DistributionPackageBuilder API in the
[PackageHandler|https://github.com/apache/sling-org-apache-sling-distribution-journal/blob/c5f92f9913a3598140a983841245113a40b89e17/src/main/java/org/apache/sling/distribution/journal/bookkeeper/PackageHandler.java#L56-L70].
However, this hack falls short when we need to specialize the handling of
packages per DistributionSubscriber agent.
We could think of introducing a PackageHandler interface and allow to hook it
per subscriber agent. However, this would extend on the original hack, start
exporting packages from the distribution.journal bundle (no export yet).
I suggest we fix the original design flaw with the proposal below.
h1. Proposal
h2. Benefits
* Simplify the journal distribution implementation (avoid the
DistributionPackageBuilder indirections, reduce call stack size)
* Conform to the Sling DistributionPackageBuilder API (no more hack)
* Unlock a clean and simple way to customise the package handling by swapping
DistributionPackageBuilder implementations via configuration of sub and pub
agents.
h2. How
Introduce a *JournalDistributionPackageBuilder* that implements its
*DistributionPackage* directly with *PackageMessage* from the
distribution.messages bundle.
h2. Risk
The DistributionSubscriber and DistributionPublisher will need to be configured
to use the new *JournalDistributionPackageBuilder*.
Risk is minimal since the *JournalDistributionPackageBuilder* will support the
same configurations as the *VaultDistributionPackageBuilderFactory* for the
*FileVaultContentSerializer*. Since the format on the wire won't change, it
would be a snap in replacement (content migration and deployment coordination
*not* needed).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
