You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Amit Mondal (Jira)" <ji...@apache.org> on 2020/07/27 11:40:00 UTC

[jira] [Created] (FELIX-6311) Configurator Ranking Issue

Amit Mondal created FELIX-6311:
----------------------------------

             Summary: Configurator Ranking Issue
                 Key: FELIX-6311
                 URL: https://issues.apache.org/jira/browse/FELIX-6311
             Project: Felix
          Issue Type: Bug
          Components: Configurator
    Affects Versions: configurator-1.0.12
            Reporter: Amit Mondal


According to the spec, if two bundles provide the different configurations for the same PID, then the configuration with the higher service ranking will be applied. It does work pretty well but not in the following scenario.

Let's say, we have two bundles (_*A*_ and _*B*_) providing different configurations under _*my.pid*_.

The configurations are as follows:

_*Bundle A*_:
{code:java}
 "my.pid" : {
       "log.level": "INFO",
       ":configurator:policy": "force"
  }{code}
_*Bundle B*_:
{code:java}
 "my.pid" : {
      "log.level": "ERROR",
      ":configurator:ranking": 200
  }{code}
According to the spec, the configuration provided by _*Bundle B*_ will eventually be stored in _*ConfigurationAdmin*_ and it does work. The only thing to notice is the policy.

The configuration in _*Bundle B*_ has a default policy. And if I change the configuration manually (for example, programmatically or using web console), I would expect it to survive runtime restarts, that is, if I restart the OSGi runtime (without cleaning the OSGi storage), the new configuration will not be replaced.

But unfortunately the manual configuration change gets replaced by the configuration provided by _*Bundle B*_ as if the configuration has a force policy (even though the policy is actually default).

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)