Open koenkicken opened 1 month ago
yes, this is sadly true. using a JCR query they bypass the persistence abstraction of context-aware configuration and assume the property is always stored in the same node. i would call this a bug in AEM, but it's unlikely to be fixed anytime soon i suppose.
so we have to think about a workaround on our side.
@stefanseifert A possible workaround that I see is making the PagePersistenceStrategy osgi config more flexible. Instead of making it a true/false value, this could be made a regex just like with the AbsoluteParentContextPathStrategy.
my proposal would be to add something like a "configNameDenyList" property to the OSGi configuration of the AEM page persistence strategy. it allows full string or regex to match against configuration names - and we would put "com.adobe.aem.wcm.site.manager.config.SiteConfig" as a default value into this list.
any configuration name matching one of these is handled the AEM page persistence strategy skips it's processing.
If
io.wcm.caconfig.extensions.persistence.impl.PagePersistenceStrategy
is enabled, then for OOTB Ca Configcom.adobe.aem.wcm.site.manager.config.SiteConfig
all the properties are saved to the underlying jcr:content node.When developing for a new Site Theme and you want to set a new frontend pipeline for it, you need to set the themePackageName for it in the SiteConfig.
However, in the implementation (
com.adobe.aem.wcm.frontend.manager.impl.SiteThemeUpdateFrontendCodeDeploymentEventListener#findSiteConfigsUsingPackage
) it performs a query to look for this property on theSiteConfig
itself, not on the jcr:content underneath.Either the PagePersistenceStrategy osgi config should be more flexible, or the SiteConfig should be excluded and never saved as a cq:Page.