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:46:00 UTC
[jira] [Updated] (FELIX-6311) Configurator Ranking Issue
[ https://issues.apache.org/jira/browse/FELIX-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Amit Mondal updated FELIX-6311:
-------------------------------
Description:
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*_).
was:
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).
> 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
> Priority: Major
>
> 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)