Timothee Maret created SLING-12704:
--------------------------------------

             Summary: Introduce a JournalDistributionPackageBuilder
                 Key: SLING-12704
                 URL: https://issues.apache.org/jira/browse/SLING-12704
             Project: Sling
          Issue Type: Improvement
          Components: Content Distribution
    Affects Versions: Content Distribution Journal Core 0.4.0
            Reporter: Timothee Maret
            Assignee: 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)

Reply via email to