Can components created by a factory component be managed by configuration admin?

GENERAL
1

I have defined a very simple component:

@Component(name = "SampleComponent", factory = "SampleComponentFactory")
public class SampleComponent {
   ...

To get an idea how things work, I have interactively created an instance with gogo:

g! factoryRef = (serviceReferences org.osgi.service.component.ComponentFactory "(component.factory=SampleComponentFactory)") 0
g! factory = service $factoryRef
g! obj = $factory newInstance null
component.name=SampleComponent
component.id=8
Instance             org.jgrapes.ap.device.dummy.SampleComponent@3e4d6537

The newly created component is known to scr (scr:list shows it), but configuration admin does not know about it (nothing from cm:listConfigurations null).

Now I’d like to configure the component with configuration admin, but I fail to see how I can reference it. None of the methods of ConfigurationAdmin seems to fit because my component doesn’t have a pid. And SampleComponentFactory~SampleComponent isn’t unique because it’s missing the id.

Is it possible to manage components created by a factory components with configuration admin? And will configuration admin restore such components on application restart? Or is this simply the wrong approach for managing components that are created in response to some input during runtime and I have to use the ManagedServiceFactory (which I frequently find to be attributed as “low level API” not required when using DS)?

2

You cannot use factory configurations with factory components since only one party can be in charge of instantiating a component instance. Either DS for each factory configuration or the caller to ComponentFactory.newInstance. See the discussion on Factory Configuration in https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-deployment.

A factory configuration must not be used if the component is a factory component. This is because SCR is not free to create component configurations as necessary to support multiple Configurations. When SCR detects this condition, it must log an error message with the Log Service, if present, and ignore the component description.

Calls to ComponentFactory.newInstance do not result in any changes to Configuration Admin as factory component instances are not persistent where as configurations are persistent.

You can use a single configuration which is used by all factory component instances. See https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-component.properties. Any properties specified to ComponentFactory.newInstance can override properties in the single configuration.

3

Thanks for clarifying this. Actually, I started the other way round, i.e. by creating a factory configuration in cm. I expected the instance of the factory component to simply appear. But, of course, org.osgi.service.component.ComponentFactory does not implement ManagedServiceFactory (with an update method that calls newInstance) – which would have been nice, though.

I read the specifications again and obviously the Managed Service Factory is intended for creating persistent services dynamically while there is simply no support for persisting instances of factory components. I’ve read the sentence “This is because SCR is not free to create component configurations as necessary to support multiple Configurations.” about a dozen times by now and I freely admit that I simply don’t understand it.

Looks like I have to provide a ManagedServiceFactory that invokes newInstance as described above myself , if I want to take advantage of cm to create and persist instances of factory components. Somehow this use case appears to be so obvious that I wonder if anybody reading this has actually already implemented such a service…

4

I might be wrong but it sounds like your making things too hard? If you want to configure components with Configuration Admin, a normal component works fine. The name is the PID. If you create factory configuration with that PID as factory PID, then for each configuration a new instance is created.

The factory field in the @Component annotation is way more complicated and only needed when you want to create instances from another component. I never ever use it.

5

Oops. Who would have thought that an ordinary component can be configured with a factory configuration. Knowing it, I can now indeed find this in the Deployment section. I had always associated factory configurations with factory components. Maybe because English isn’t my native language, maybe because I had read Configuration Admin before DS (IMHO CM is much clearer about factories) or maybe because there’s simply too much use of the term factory in all of this.

Thank you very much!

6

DS is quite a swiss army knife … And although the spec is good, it misses a good introduction book. A pity because it is amazingly powerful.