Hi, I stumbled across some behavior that doesn't seem right to me regarding how "writeback" jcrinstall (or fileinstall) configurations are being handled for PIDs that are also declared in a feature model.
Here are some quick repro steps using the starter project: 1. Initially there is a "org.apache.sling.commons.log.LogManager" configuration defined in the base.json feature model 2. Launch the starter. At this point the logging is going to the "logs/error.log" file as defined in the initial configuration defined in the feature model. 3. Open the "org.apache.sling.commons.log.LogManager" configuration in the webconsole and change the "Log File" value to "logs/error2.log" and apply it. The modified writeback configuration is saved in the repository at /apps/sling/install/org.apache.sling.commons.log.LogManager.cfg.json 4. At this point the logging begins going to the logs/error2.log file and it all seems good. 5. Now stop and restart the starter 6. After the restart the log file goes back to the original "logs/error.log" location. It appears that the "writeback" configuration that is still stored in the repository at /apps/sling/install/org.apache.sling.commons.log.LogManager.cfg.json is not used anymore? So I am requesting some clarification on what the precedence of selecting a configuration should be when jcrinstall (or fileinstall) and feature model values are both available after a restart. I was expecting that the configuration stored at /apps/sling/install/org.apache.sling.commons.log.LogManager.cfg.json would have a higher priority than what was defined in the feature model. For comparison: when there is no configuration for a PID in the feature model, then it does load the writeback configuration so the behavior is different. Have I missed something or any other thoughts? Regards, Eric
