Community
Participate
Working Groups
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
Created attachment 178494 [details] propagates config admin properties to service registration
This needs to be re-tested with 2.0.0
Assigned to upcoming milestone
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!
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.
Released - closing.
