Requesting clarification on the expected component configuration precedence

[Eric Norman <en...@apache.org>]

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

Re: Requesting clarification on the expected component configuration precedence

[Eric Norman <en...@apache.org>]

Hi Robert,

I can certainly disable writeback (or remove the jcr-installer-provider
completely), but that does make the usefulness of the webconsole somewhat
limited.  Any changes to configuration via the webconsole are gone after
the server has restarted which isn't what I was expecting.

Are you suggesting that a new "Feature Model Installer Provider"
implementation would be required to write back the configuration changes to
a feature model json file that can be loaded as additional arguments to the
launcher script?

For example:

launcher -f feature-oak_tar.json -f webconsole-writeback-configs.json -CC
"*=MERGE_LATEST"


If that is the right approach, then maybe it would be good to detect that
the feature model is being used and disable the writeback support form
jcr-install-provider and file-install-provider automatically so it isn't so
confusing?

Regards,
Eric

On Wed, Dec 7, 2022 at 5:04 AM Robert Munteanu <ro...@apache.org> wrote:

> Hi Eric,
>
> On Sun, 2022-11-27 at 12:38 -0800, Eric Norman wrote:
> > Have I missed something or any other thoughts?
>
> I am not an expert in this area, but I think this is a scenario where
> the feature model and the OSGi installer conflict. Have you tried
> disabling the writeback for the installer, as documented at [1]?
>
> Thanks,
> Robert
>
> [1]:
>
> https://sling.apache.org/documentation/bundles/jcr-installer-provider.html#write-back-support-1
>

Re: Requesting clarification on the expected component configuration precedence

[Robert Munteanu <ro...@apache.org>]

Hi Eric,

On Sun, 2022-11-27 at 12:38 -0800, Eric Norman wrote:
> Have I missed something or any other thoughts?

I am not an expert in this area, but I think this is a scenario where
the feature model and the OSGi installer conflict. Have you tried
disabling the writeback for the installer, as documented at [1]?

Thanks,
Robert

[1]:
https://sling.apache.org/documentation/bundles/jcr-installer-provider.html#write-back-support-1