Creations or updates of EnsureOakIndex configurations get picked up #3402
Conversation
jasper-s
force-pushed
the
defect/ensure-oak-index/pickup-changed-configurations
branch
from
63094e4
to
e76004b
Compare
| @@ -48,7 +48,8 @@ | |||
| description = "Component Factory to manage Oak indexes.", | |||
| configurationFactory = true, | |||
| policy = ConfigurationPolicy.REQUIRE, | |||
| metatype = true | |||
| metatype = true, | |||
| immediate = true | |||
There was a problem hiding this comment.
No need for this, they will be started ASAP if they are referenced in greedy fashion.
There was a problem hiding this comment.
It seems like my AEM instance disagrees with that statement. I also expected that, but without immediate=true all EnsureOakIndex components remain in the "satisfied" state
There was a problem hiding this comment.
I have looked around in OSGi documentation and could not find any indication that the greedy reference makes immediate obsolete.
There was a problem hiding this comment.
According to https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-delayed.component every registered component is becoming active as soon as it is referenced. As greedy references always look for new services in the service registry (https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#d0e37698) and bind them it shouldn't make a difference if the service is immediately activated or just activated once bound.
There was a problem hiding this comment.
I updated the EnsureOakIndex class to use the org.osgi.service.component.annotations.* annotations, and tested again whether the immediate activation is required.
While I agree that based on that documentation you provided it should work, I cannot get it to work without immediate activation in practice.
There was a problem hiding this comment.
@kwin, any suggestions on how to move forward?
There was a problem hiding this comment.
I did some more digging around. While the EnsureOakIndex references do get bound to the EnsureOakIndexManagerImpl component, the EnsureOakIndex components remain satifsfied.
It seems like the binding of the references is happening as described in the documentation, but that the components are not actived as expected.
There was a problem hiding this comment.
The cause seems to be the circular reference where EnsureOakIndex components reference the EnsureOakIndexManager. When removing that reference, activation of all components works as expected without the immediate property.
The reference is required of course, so the addition of immediate seems to be the most realistic option.
There was a problem hiding this comment.
I updated the circular reference to make that optional & greedy. Now immediate is no longer required.
@kwin, let me know which you prefer.
jasper-s
force-pushed
the
defect/ensure-oak-index/pickup-changed-configurations
branch
3 times, most recently
from
027f372
to
8083db8
Compare
jasper-s
force-pushed
the
defect/ensure-oak-index/pickup-changed-configurations
branch
from
8083db8
to
8510673
Compare
jasper-s
force-pushed
the
defect/ensure-oak-index/pickup-changed-configurations
branch
from
8510673
to
49981c5
Compare
davidjgonzalez
merged commit de543af
into
Adobe-Consulting-Services:master
…dobe-Consulting-Services#3402) * Creations or updates of EnsureOakIndex configurations get picked up * Update EnsureOakIndex OSGi annotations * Update EnsureOakIndexManagerImpl to OSGi annotations --------- Co-authored-by: Jasper Simon <jasper.simon2@kbc.be> Co-authored-by: david g. <davidjgonzalez@users.noreply.github.com>
The EnsureOakIndexManagerImpl was not consistently picking up changes to EnsureOakIndex configurations, as well as ignoring additional configurations until it was restarted.
Setting the referencePolicyOption to Greedy guarantees additional services are picked up when they become active, while the immediate flag makes them active immediately.