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

ConfigurationPlugins support for DI engines #1171

Closed bjhargrave closed 12 years ago

bjhargrave commented 15 years ago

Original bug ID: BZ#1272 From: Simon Kaegi <simon_kaegi@ca.ibm.com> Reported version: R4 V4.2

bjhargrave commented 15 years ago

Comment author: Simon Kaegi <simon_kaegi@ca.ibm.com>

In {112.7 Deployment} of the Declarative Service chapter there is a section on consuming properties from Configration Admin that alludes to being similar to "the ManagedService and ManagedServiceFactory situation". In a later section there is talk about retrieving "Configuration" objects.

One difference between retrieving Configuration objects vs. using a Managed Service is that "ConfigurationPlugins" only come into play for ManagedServices and ManagedServiceFactories.

Do we want to allow ConfigurationPlugins to be involved when configuring services using DS in the same way they are when using a ManagedService?

bjhargrave commented 15 years ago

Comment author: @bjhargrave

I have removed the text "the ManagedService and ManagedServiceFactory situation" from the spec draft.

DS does not mandate that the DS impl use ConfigAdmin api or Managed[Factory]Service services to get the Configurations. Although most will use the ConfigAdmin API. We certainly should not require DS impls to use Managed[Factory]Service since that will result in an excessive number of Managed[Factory]Service service registrations.

Of course we could suggest DS impl call the ConfigurationPlugins directly. But this does not seem possible based upon the ConfigurationPlugin API which needs a ServiceReference to the Managed[Factory]Service which does not exist in the DS case.

I think ConfigurationPlugin is silly anyway. It smacks of some silly compromise when the ConfigAdmin spec was created :-)

bjhargrave commented 15 years ago

Comment author: @bjhargrave

CPEG Call: Peter suggests that DS/Blueprint register a single service which implement ManagedService and ManagedServiceFactory with service.pid set to all of the pids of interest.

This will mean that CM implementation must respond to service modifications and notify the target of the configurations for the newly present pids.

bjhargrave commented 15 years ago

Comment author: @bjhargrave

CPEG Call: Peter suggests that DS/Blueprint register a single service which implement ManagedService and ManagedServiceFactory with service.pid set to all of the pids of interest.

This will mean that CM implementation must respond to service modifications and notify the target of the configurations for the newly present pids.

Peter's suggestion depends upon bug BZ#1258.

bjhargrave commented 14 years ago

Comment author: @bjhargrave

CPEG mtg: Decided it would be better to provide a method on Configuration to return the plugin mutated Dictionary. This could be used by DS and Blueprint to get the mutated configuration.

bjhargrave commented 14 years ago

Comment author: @bjhargrave

Peter,

Can you include the change per comment 4 in RFC 165?

bjhargrave commented 13 years ago

Comment author: @pkriens

Suggest we kill the plugin in cm 2.0

bjhargrave commented 13 years ago

Comment author: @bjhargrave

CPEG mtg: Make part of RFC 165 changes to Config Admin. We will deprecate ConfigurationPlugin.

bjhargrave commented 12 years ago

Comment author: @bjhargrave

Peter, what shall we do about this bug and the CM changes in RFC 165?

bjhargrave commented 12 years ago

Comment author: Felix Meschberger <fmeschbe@adobe.com>

For reference: Mail thread from osgi-dev hitting the same issue is http://www.mail-archive.com/osgi-dev@ mail.osgi.org/msg02021.html

bjhargrave commented 12 years ago

Comment author: @bjhargrave

Maybe we need a method on ConfiguationAdmin where the caller can supply a configuration Dictionary, and the CM impl will call the registered ConfigurationPlugins to mutate the configuration. But we still have the issue of what ServiceReference to supply to each ConfigurationPlugin since there is no actual MS/MSF.

bjhargrave commented 12 years ago

Comment author: Felix Meschberger <fmeschbe@adobe.com>

I am not sure about a method to apply ConfigurationPlugin to a Dictionary.

From the POV of DS it would be sufficient to have a method get a Configuration by PID to which the ConfigurationPlugins have been applied. As per your comment BZ#4.

bjhargrave commented 12 years ago

Comment author: @pkriens

Have added this feature to RFC 165 so it will be tracked from there

bjhargrave commented 12 years ago

Comment author: @bjhargrave

CPEG mtg: Agreed to remove this from RFC 165. There is no big driver for this and there were objected that the method encouraged "lying" since the caller of the proposed method must fabricate a MS/MSF to pass to the plugins.

5.4 Configuration with Plugin Updates The Configuration interface is extended with the following method: Dictionary<String,Object> getProperties(ServiceReference ref) The method returns an unmodifiable Dictionary with the properties after they've been modified by the plugins. The Service Reference must not be null.