[
https://issues.apache.org/jira/browse/SLING-12687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17932324#comment-17932324
]
Timothee Maret commented on SLING-12687:
----------------------------------------
https://github.com/apache/sling-org-apache-sling-distribution-core/pull/70
> 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
> Assignee: Timothee Maret
> Priority: Major
> 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)
