Log OSGi Configuration Changes

[rp12]

I want to log following information when any changes are made to an OSGi Configuration

• What configuration was changed
• Who changed the configuration
• What configuration values were updated and what the updates were

I created an EventListener to handle event topic org/apache/felix/webconsole/plugins/event/internal/converter/ConfigurationEventConverter/CM_UPDATED. But this is not working.

I also created a listener to implement ConfigurationListener to handle the changes. This is capturing the events but there are following issues

• Two events (CM_UPDATED, CM_LOCATION_CHANGED) are logged when any configuration is added or modified.
• No event is logged is configuration is moved.

I also observed that lastModifiedBy property has a value as sling-jcr-install and not by the person who actually modified the configuration.

Is there any way to log these changes?

Really appreciate any help on this.

Thanks,

Ritesh

[Vijayalakshmi_S]

Hi @rp12, 

On checking org.apache.felix.webconsole.plugins.event bundle (Version 1.1.8 as available in AEM 6.5.0), could see event types - CM_UPDATED and CM_DELETED alone. 

Could you please let know

• If you are updating the config directly in Felix or via code deployment when you observed the lastModified as System user - sling-jcr-install
• The scenario in which you observed CM_LOCATION_CHANGED event. 

[rp12]

Hi @Vijayalakshmi_S,

I updated OSGi configurations from /system/console/configMgr and observed lastModifiedBy as sling-jcr-install.

Regarding CM_LOCATION_CHANGED, I observed this event is triggered when I get configuration configurationAdmin. Also this event is not found at /system/console/events.

Configuration readConfig = configurationAdmin.getConfiguration(event.getPid());

If I comment this, I observed only CM_UPDATED or CM_DELETED events

Thanks,

Ritesh

[Jörg_Hoh · Accepted solution]

I would like to question the reason for this requirement.

If I would need to guess, I could make up a story, where problems occured in PROD, which were not reproducible on any other environment. It caused huge pain until someone figured out that a change was made directly in the OSGI webconsole which was causing this problem. And now you want to ensure that you get at least immediately aware if someone is performing such a change.

The problem with your approach is, that no user information is ever sent along with that change information. If you tend to ignore this and rather want to focus on identification of that change, I would log all those changes, no matter if duplicate or not. In the end, these events should not happen at all, and must be handled manually anway.