Set OSGi Component properties dynamically using OCD - Use case with Sling ResourceChangeListener | AEM Community Blog Seeding

[kautuk_sahni]

Set OSGi Component properties dynamically using OCD - Use case with Sling ResourceChangeListener by Vijayalakshmi

Abstract

In general, per OSGi R6 annotations and above, we can set OSGi component properties via

property attribute of @Component annotation (Static values) or
Dynamically using @ObjectClassDefinition together with @AttributeDefinition (property amends in run time via Config Admin or /system/console/configMgr)
AttributeDefinition should be framed such that it evaluates to the property name correctly (underscores are converted to dots/period)
Association of OCD with OSGi component happens via annotation named @Designate
Example : Component properties like service.ranking and in case of specific implementations like say WorkflowProcess, we set property named process.label and for EventHandler, it is EventConstants.EVENT_TOPIC and examples add on in a similar fashion for any OSGi Component for that matter.

In order to illustrate this, I would like to consider Sling ResourceChangeListener which expects the PATHS (mandatory property) to which it should listen to and optional CHANGES (added/removed/changed) and PROPERTY_NAMES_HINT (property name on the resource)

For static property values, we would write an Implementation for Listener like below. Sling ResourceChangeListener

Now for amending properties dynamically via Config Admin, we can create OCD in a separate file or within the same OSGi component.
In this case, ResourceChangeListener.PATHS is a field for the constant value - resource.paths. Hence @AttributeDefinition would be resource_paths(). Same way for other two properties.

Read Full Blog

Set OSGi Component properties dynamically using OCD - Use case with Sling ResourceChangeListener

Q&A

Please use this thread to ask the related questions.