Am 21.10.15 um 11:52 schrieb Julian Sedding: > Hi all (and Carsten in particular) > > I observed the following situation on a Sling instance (CQ 5.6.1 > actually) with jcr provider version 3.1.6 installed. After installing > a Jackrabbit FileVault package with multiple configurations in > multiple run-mode specific folders, an incorrect configuration was > active and written back to the repository. > > The following two configurations are installed as sling:OsgiConfig > nodes (names shortened for readability), runmode "prod" is active: > > /apps/foo/config/o.a.s.c.log.LogManager.factory.config-foobar (log-level: > debug) > /apps/foo/config.prod/o.a.s.c..log.LogManager.factory.config-foobar > (log-level: warn) > > A few seconds after the installation of this package the second > configuration is replaced by > > /apps/foo/config.prod/o.a.s.c..log.LogManager.factory.config-foobar.config > (log-level: debug). > > Now my hypothesis: > During installation of JR FileVault packages changes are saved every > ~1024 nodes. I assume the first configuration node is saved before the > "prod"-specific one. > > The first config node is scheduled for installation, installed and > ConfigAdmin fires a config added or changed event, triggering a > write-back. However, in the meantime JcrInstaller has discovered the > "prod"-specific config node and, because it has a higher weight, > selects its location for the write-back. The related InstallResource > task for the "prod"-specific config then leads to a no-op, because > after the writeback it is identical to the first config. > > Does this scenario sound plausible at all? > Yeah, this might be the case. You can easily test by disabling the intermediate saves.
Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
