You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Mark Adamcin (JIRA)" <ji...@apache.org> on 2016/10/18 21:27:58 UTC
[jira] [Updated] (SLING-6172) Sling Rewriter pipelines should
support runmode-sensitive configurations via OSGi
[ https://issues.apache.org/jira/browse/SLING-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Adamcin updated SLING-6172:
--------------------------------
Attachment: 0001-Add-initial-OSGi-Config-Support-to-Rewriter.patch
> Sling Rewriter pipelines should support runmode-sensitive configurations via OSGi
> ---------------------------------------------------------------------------------
>
> Key: SLING-6172
> URL: https://issues.apache.org/jira/browse/SLING-6172
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Affects Versions: Rewriter 1.2.0
> Reporter: Mark Adamcin
> Attachments: 0001-Add-initial-OSGi-Config-Support-to-Rewriter.patch
>
>
> I have, a number of times, run into a situation where I need to be able to selectively override the AEM default rewriter pipeline based on run mode. I read the discussion in a relevant thread (http://apache-sling.73963.n3.nabble.com/Configure-rewriter-pipeline-per-runmode-td4022918.html) and based on the implementation of ProcessorManagerImpl, it seems that extending the observed config resource paths is the most expedient way to make this happen without changing the existing behavior with respect to config/rewriter paths, and without reimplementing everything for an OSGi-config-centric approach.
> The attached patch file introduces a private configuration factory class called ProcessorConfigurationMapping that requires only a mapped.path property intended to refer to a single rewriter pipeline config node under the Resource Resolver search path, but that wouldn't be discovered by the current ProcessorManagerImpl implementation.
> The ProcessorManagerImpl has been modified to bind 0..n [static|greedy] ProcessorConfigurationMapping instances and to use these mappings to find additional config resources during initProcessors() as well as to populate the ResourceChangeListener configuration with additional observation paths during activation.
> Once activated, the ProcessorManagerImpl treats ResourceChange events on these mapped paths just like changes to config/rewriter children.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)