Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 324829

Summary:

Propagate ConfigurationAdmin properties to service instance properties

Product:

[RT] Gemini.Blueprint

Reporter:

Aleksander Bandelj <aleksander.bandelj>

Component:

Core

Assignee:

Project Inbox <gemini.blueprint-inbox>

Status:

CLOSED WONTFIX

QA Contact:

Severity:

enhancement

Priority:

CC:

olaf

Version:

2.0.0 RELEASE

Target Milestone:

2.1.0.M02

Hardware:

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
propagates config admin properties to service registration	none

Description Aleksander Bandelj

2010-09-09 05:44:59 EDT

Build Identifier: I20100608-0911

This is an echo of

https://issues.springframework.org/browse/OSGI-747

There should be a way to access ConfigurationAdmin properties for registered service inside service registration listener. For example, configuration map contains osgi.jndi.service.name, it should be accessible in property map passed to <registration-listener/> bind method.

(properties with such names don't map to bean setter names, so accessing them inside bean template is problematic, but that is another enhancement)

attached patch to HEAD propagates all properties which are not overriden in <service-properties/>. I think it's a reasonable default.

This could be configurable, for example:

<service-properties propagate="true">
</service-properties>

or with property interpolation

<service-properties>
   <entry key="osgi.jndi.service.name" value="${osgi.jndi.service.name}"/>
</service-properties>



Reproducible: Always

Comment 1 Aleksander Bandelj

2010-09-09 05:47:19 EDT

Created attachment 178494 [details]
propagates config admin properties to service registration

Comment 2 Olaf Otto

2016-04-28 07:49:27 EDT

This needs to be re-tested with 2.0.0

Comment 3 Olaf Otto

2017-02-03 06:21:32 EST

Assigned to upcoming milestone

Comment 4 Olaf Otto

2017-03-28 03:35:06 EDT

Original issue report: https://jira.spring.io/browse/OSGI-747.

It also contains the rationale behind this change:

"I would like to customize configuration for service instance created from managed service factory, so I can then filter service instances on certain properties. In other words, it would be useful to pass configuration admin properties used by osgix:managed-service-factory to created service instance or provide a hook to customize these properties."

Sounds like a great idea, investigating the patch!

Comment 5 Olaf Otto

2017-03-28 06:52:25 EDT

I will not implement this change, here is why:

By design, the service instances created by Managed Service Factories are immutable, i.e. they are created once using the configuration supplied by (and to) the factory and not updated. The service exhibit only service-specific properties, not including the additional configuration properties provided via the factory.

This is true not only for gemini-blueprint, but also for other managed service factory implementations, e.g. Apache Felix.

Now, when one wants to change that by adding the configuration properties to the services created by the factory, adding the default configs does not suffice - one would also have to update each service instance whenever the configuration changes (or destroy and re-create the service instance). For consistency, this scheme must not only apply to the managed service factory, but also by anything created via the ConfigAdminPropertiesFactoryBean (which already has the notion of updateable and changeable properties) .

Thus, this change implies that we all managed services and properties become dynamic by default and that the notion of service and configuration properties are essentially the same. Thus, any service configured by blueprint should export the config properties as service properties. This would be a clear deviation from the default and does not match the behavior of other OSGi implementations, making the approach undesirable.

Finally, the changes documented in https://jira.spring.io/browse/OSGI-747 allow for the specification of <service-properties> below the managed-service-factory, thus making it possible to define additional custom service properties, though not covering the entire use case.

Comment 6 Olaf Otto

2017-05-09 09:41:40 EDT

Released - closing.