search

osgi / bugzilla-archive

Archive of OSGi Alliance Specification Bugzilla bugs. The Specification Bugzilla system was decommissioned with the move to GitHub. The issues in this repository are imported from the Specification Bugzilla system for archival purposes.
0 stars 1 forks source link

[rfc 227][CM]Support ConfigurationPlugin-like behavior for non-MS/MSF users #2776

Closed bjhargrave closed 8 years ago

bjhargrave commented 8 years ago

Original bug ID: BZ#2908 From: @cziegeler Reported version: R7

bjhargrave commented 8 years ago

Comment author: @cziegeler

The ConfigurationPlugin defined in the Configuration Admin Spec is invoked before a configuration is delivered to a ManagedService(Factory). The plugin is able to modify the configuration properties. There are several use cases like replacing configuration values with values provided through system properties (or similar mechanism), decode values, or provide additional properties.

Right now, for components managed by DS it depends on the implementation of DS whether a ConfigurationPlugin is used: while older versions of Apache Felix SCR registered a ManagedService on behalf of the component, later versions switched to configuration listeners.

It would be great, if we could add a requirement in the DS spec that ConfigurationPlugins should always be valued. If the DS impl is not registering ManagedServices it can simply mimic the same behaviour.

bjhargrave commented 8 years ago

Comment author: David Jencks <djencks@us.ibm.com>

I wonder if the configuration admin spec should have been updated a couple of spec revisions ago. It says that a config admin instance should apply all the configuration plugins in the service registry, not just the ones that are visible to it or to the target managed service or managed service factory. I'd expect that the ConfigurationPlugins visible to the bundle with the target MS or MSF would be the best choice.

In any case, I like this idea, I've wanted configuration plugin functionality for DS for quite some time.

bjhargrave commented 8 years ago

Comment author: @bjhargrave

ConfigurationPlugin is designed to receive a ServiceReference to the target ManagedService/ManagedServiceFactory object. If SCR is to call ConfigurationPlugins, what ServiceReference must is pass when it does not register a MS/MSF on behalf of each component?

I think the concept of ConfigurationPlugin is basically old and somewhat broken since it only works if there is a MS/MSF to receive the Configuration.

If we want SCR to support ConfigurationPlugins, we should instead change the CM API to provide a means to receive a mutated Configuration from CM instead of asking SCR to attempt to replicate the behavior. Then SCR can be changed to use that new CM mechanism. I think it would be wrong to change the DS spec to require SCR to replicate the ConfigurationPlugin behavior.

bjhargrave commented 8 years ago

Comment author: @rinswind

I second that. If this is to be done the best place is either CM or Configurer.

There is a general need to filter configurations prior to their delivery to interested parties. A 'ConfigurationFilter' of sorts is needed and it should likely be applied as configurations are first stored in CM. There are dynamics issues to resolve here though, as filters can come and go at any time and also configurations can be invalid without a certain chain of filter being applied. Software AG attempted to use ConfigurationPlugins for filtering and we are about to completely drop the approach in favor of a home grown solution. ConfigurationPlugins are broken.

bjhargrave commented 8 years ago

Comment author: @cziegeler

I'm not against coming up with a better aproach as ConfigurationPlugin. Whatever we come up with, it should in the first place be part of CM. There are two features of ConfigurationPlugin which we somehow should keep:

The initial RFP for Configurer had a mechanism for placeholders in the configuration which then got replaced by the Configurer before the configurations are stored in CM. We decided against this and dropped it as it's too static and does the replacement at the wrong point of time.

bjhargrave commented 8 years ago

Comment author: @bjhargrave

So I think the consensus is forming that we need an RFC for CM changes and not a change to DS.

bjhargrave commented 8 years ago

Comment author: @rinswind

Carsten's second requirement seems to imply there should be one mechanism to deliver events to tools and another to configuration consumers. Which matches very well the distinction between ConfigurationListener and ManagedService.

Does anyone know why did DS move away from ManagedServices?

The fact that the equinox DS uses a single ConfigurationListener to manage all bundles is one of the reasons we are going to move away from ConfigurationPlugins, as we can't filter configurations when they are consumed by DS. Also if DS exports a ManagedService(Factory) on behalf of the processed bundle it is easy to understand which bundles use which configurations by just inspecting the registered ManagedServices. It seems more natural than to use DS-specific console commands. It seems to me that ManagedService should not have been abandoned.

bjhargrave commented 8 years ago

Comment author: @bjhargrave

(In reply to Todor Boev from comment BZ#6)

Carsten's second requirement seems to imply there should be one mechanism to deliver events to tools and another to configuration consumers. Which matches very well the distinction between ConfigurationListener and ManagedService.

I think that perhaps we just need CM to provide a way to obtain a Configuration after ConfigurationPlugin type processing.

Does anyone know why did DS move away from ManagedServices?

DS never moved away from MS/MSF. It never was required to use MS/MSF. An SCR implementation is free to obtain a component's configuration as it sees fit. Requiring SCR to register an MS/MSF on behalf of each component was seen as too much.

Also, SCR does not know in advance whether the configurations for a component is a singleton or factory, so then it cannot know whether to register an MS or MSF until it has already seen the configuration information. :-)

bjhargrave commented 8 years ago

Comment author: @cziegeler

(In reply to BJ Hargrave from comment BZ#7)

I think that perhaps we just need CM to provide a way to obtain a Configuration after ConfigurationPlugin type processing.

The problem here is the same with adding support for ConfigurationPlugin to DS: there is no managed service and/or no service reference.

I could imagine that we have to come up with a different interface similar to ConfigurationPlugin but instead of a ServiceReference we might pass in the bundle which wants to use the configuration. And then maybe add a filter() method in some way to CM. So SCR could get the configuration as today, call filter() on CM which then calls the plugins (or whatever we call them) and gets back the final configuration. But maybe there is a better option?

bjhargrave commented 8 years ago

Comment author: @bjhargrave

(In reply to Carsten Ziegeler from comment BZ#8)

I could imagine

This is why we need someone to propose an RFC to update CM! :-)

bjhargrave commented 8 years ago

Comment author: @cziegeler

(In reply to BJ Hargrave from comment BZ#9)

(In reply to Carsten Ziegeler from comment BZ#8)

I could imagine

This is why we need someone to propose an RFC to update CM! :-)

:) I think it would make sense to add this to RFC 218 Configurer - we have already several CM updates in there. I'll do that in the next days

bjhargrave commented 8 years ago

Comment author: @rinswind

It is not just ConfigurationListener. All DS implementations there seem to register a single global ServiceListener as well. This then breaks specs like Remote Service Admin that count on registered ServiceListeners with precise filters to register remote service clients in a Just In Time manner.

Making CM even more complicated doesn't seem very nice.

Is it too late to strengthen the DS spec so:

In general a bundle that is backed by DS should behave like a bundle that is coded by hand against the raw OSGi API.

p.s. CDI could be on the way to make the same mistakes as DS.

bjhargrave commented 8 years ago

Comment author: @bjhargrave

(In reply to Carsten Ziegeler from comment BZ#10)

(In reply to BJ Hargrave from comment BZ#9)

(In reply to Carsten Ziegeler from comment BZ#8)

I could imagine

This is why we need someone to propose an RFC to update CM! :-)

:) I think it would make sense to add this to RFC 218 Configurer - we have already several CM updates in there. I'll do that in the next days

Well in someways, if we have enough CM changes, it may be better to have a separate RFC so they are not lost on the Configurator RFC (should it fail for some reason).

bjhargrave commented 8 years ago

Comment author: @bjhargrave

(In reply to Todor Boev from comment BZ#11)

It is not just ConfigurationListener. All DS implementations there seem to register a single global ServiceListener as well. This then breaks specs like Remote Service Admin that count on registered ServiceListeners with precise filters to register remote service clients in a Just In Time manner.

This is already though about during RSA design. This is the point of the UnfilteredServiceListener. SCR would use that to receive all service events but advertise the interests of components it is managing through the filter. See 5.6 in the Core spec.

Making CM even more complicated doesn't seem very nice.

But making DS does? :-) It is better to centralize the behavior rather than requiring all others to duplicate the behavior.

Is it too late to strengthen the DS spec so:

  • Components define in the XML if they are configured with a singleton or factory configuration. Factory could be the default when nothing is said.

I think it is too late and I am not sure of the value

  • DS registers an MS/MSF for every PID on behalf of the extended bundle.

This is over specification.

  • DS registers a ServiceListener with an exact filter for every imported service on behalf of the extended bundle.

This is also over specification and the spec already has UnfilteredServiceListener for SCR to use.

In general a bundle that is backed by DS should behave like a bundle that is coded by hand against the raw OSGi API.

I don't think I agree. In the sense that any services provided and consumed by the component are related to the component bundle's context, I agree. But as to how that component was managed, we do not want to require the bundle appear to be using MS/MSF and ServiceListeners.

p.s. CDI could be on the way to make the same mistakes as DS.

CDI has its own set of issues since the lifecycle of CDI beans does not match that of OSGi services. And, CDI would benefit from centralizing CM behavior since it would not have to reimplement it.

bjhargrave commented 8 years ago

Comment author: @rinswind

The idea is that the use of an extender should be transparent with respect to both resource tracking (MS/MSF, ServiceListener) and resource utilization (obtaining service via the bundle's BundleContext). This is important because third parties can observe both how resources are utilized and how they are tracked (e.g. service hooks and the RSA). This is not just about transparently switching back between hand written code, DS, and another extender. It is about the principle of least surprise. It is most natural to expect that a bundle both tracks and consumes it's dependencies through its own context (when analyzing bugs using the console for example).

I was not aware that the non-transparent behavior of DS was fixed via a special ServiceListener rather then by a stronger (i.e overs-specified) DS contract.

I realize this discussion was probably concluded a very long time ago so these are just my two (very late) cents.

bjhargrave commented 8 years ago

Comment author: John Ross <jwross@us.ibm.com>

Do we need to consider the Blueprint spec in addition to DS here?

bjhargrave commented 8 years ago

Comment author: @bjhargrave

(In reply to John Ross from comment BZ#15)

Do we need to consider the Blueprint spec in addition to DS here?

Depending upon the solution, extenders which obtain configurations for extendees may need to change to obtain the decorated configuration as prescribed by the solution.

So yes, both DS and Blueprint specs would need to change here. But changing Blueprint spec will require someone to step up and change the spec, RI and CT for a new version of the spec.

bjhargrave commented 8 years ago

Comment author: @cziegeler

This is part of RFC 227 now