[
https://issues.apache.org/jira/browse/ARIES-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16133028#comment-16133028
]
Grzegorz Grzybek edited comment on ARIES-1732 at 8/21/17 5:49 AM:
------------------------------------------------------------------
Even if I found another solution to "multiple {{<cm:property-placeholder>>}}
declarations for single PID" (ensuring that the configuration has "?" set as
location, so {{org.apache.felix.cm.impl.ConfigurationManager#canReceive()}}
returns {{true}} for all bundles), I still believe that Paolo's fix is fine.
I mean - if someone creates:
{code:xml}
<cm:property-placeholder persistent-id="test" />
{code}
(s)he doesn't expect the PID to be empty - and in fact doesn't expect CM to be
unavailable.
So my idea is to change
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#updated()}} to:
* not accept null properties when
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} is
false
* not change
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} to
true when it's false and props are empty
* accept null properties when
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} is
true (in case blueprint bundle is not restarted, but the PID is removed) -
looks like currently it's not happening...
What do you think?
was (Author: gzres):
Even if I found another solution to "multiple {{<cm:property-placeholder>>}}
declarations for single PID" (ensuring that the configuration has "?" set as
location, so {{org.apache.felix.cm.impl.ConfigurationManager#canReceive()}}
returns {{true}} for all bundles), I still believe that Paolo's fix is fine.
I mean - if someone creates:
{code:xml}
<cm:property-placeholder persistent-id="test" />
{code}
(s)he doesn't expect the PID to be empty - and in fact doesn't expect CM to be
unavailable.
So my idea is to change
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#updated()}} to:
* not accept null properties when
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} is
false
* not change
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} to
true when it's false and props are empty
* accept null properties when
{{org.apache.aries.blueprint.compendium.cm.CmManagedProperties#initialized}} is
true (in case blueprint bundle is not restarted, but the PID is removed)
What do you think?
> blueprint-cm - race condition
> -----------------------------
>
> Key: ARIES-1732
> URL: https://issues.apache.org/jira/browse/ARIES-1732
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
> Reporter: Paolo Antinori
> Assignee: Grzegorz Grzybek
>
> There is a possible race condition in
> `org.apache.aries.blueprint.compendium.cm.CmPropertyPlaceholder` and
> `org.apache.aries.blueprint.compendium.cm.ManagedObjectManager`
> There are situations where `ConfigAdmin` service might not be available and
> returns `null` when queried for the initial `config`.
> In other cases instead, `CmPropertyPlaceholder` receives updates from
> `ConfigAdmin` thread even before it has completed it's initialization.
> The code doesn't discriminate if `config` is `null` or not, and treats any
> value as valid, marking `CmPropertyPlaceholder` instance as initialized.
> This leads to spotty errors.
> The suggested fix, that simply prevents that `update(null)` invocation mark
> the `CmPropertyPlaceholder` instance as initialized, addresses the issue.
> Code here:
> https://github.com/apache/aries/compare/trunk...paoloantinori:ENTESB-7141?expand=1
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
