These are absolutely not the same things! <tldr>
You always want this one. In ten years I have used this hundreds of times, I have never used the other setup. > @Component( > configurationPid = “com.my.component”) > @Designate( > factory = true, > ocd = MyConfig.class) > public class MyComponent > implements MyComponentInterface > {….} </tldr> The factory element of the @Component annotation has nothing to do with factory configurations from configuration admin. See the java doc for details <https://osgi.org/javadoc/r6/cmpn/org/osgi/service/component/annotations/Component.html#factory()>. I strongly doubt that you really want to declare your component as a factory. This is an uncommon way to control the lifecycle of a DS component, and it is almost always set in a mistaken attempt to indicate that you want to use the muliton pattern. The important thing from the perspective of the multiton pattern is your configurationPolicy. In summary: > @Component( > configurationPid = “com.my.component”) This means "Use this PID when configuring my component” > @Component( > configurationPid = “com.my.component”, configurationPolicy=REQUIRE) This means “Use this PID when configuring my component, and require configuration before it is activated. This also enables the multiton pattern. > @Component( > factory = “com.my.component”) This means “Register a DS ComponentFactory service with this factory name so that I can use the DS API to create instances programatically”. —— Now the @Designate annotation is part of the Metatype spec, and it does have an interesting interaction with the @Component annotation. Specifically: > @Component > @Designate( > factory = false, // the default > ocd = MyConfig.class) This component will have a configuration policy of OPTIONAL > @Component > @Designate( > factory = true, > ocd = MyConfig.class) This component will have a configuration policy of REQUIRE. This is why you can get away without specifying a configuration policy when using the @Designate annotation. Again, the java doc for configurationPolicy <https://osgi.org/javadoc/r6/cmpn/org/osgi/service/component/annotations/Component.html#configurationPolicy()> is helpful. Tim > On 27 Sep 2018, at 21:49, Leschke, Scott via osgi-dev > <osgi-dev@mail.osgi.org> wrote: > > Just to be clear, I thought this: > > @Component( > configurationPid = “com.my.component”) > @Designate( > factory = true, > ocd = MyConfig.class) > public class MyComponent > implements MyComponentInterface > {….} > > Was equivalent to this: > > @Component( > factory = “com.my.component”) > @Designate( > ocd = MyConfig.class) > public class MyComponent > implements MyComponentInterface > {….} > > Is that not the case? It doesn’t appear to be based on my experiment. I > didn’t find the API docs helpful on this. > > Regards, > > Scott Leschke > > From: osgi-dev-boun...@mail.osgi.org <osgi-dev-boun...@mail.osgi.org> On > Behalf Of Leschke, Scott via osgi-dev > Sent: Thursday, September 27, 2018 10:52 AM > To: osgi-dev@mail.osgi.org > Subject: [osgi-dev] configurationPid vs factory identifier > > How is the factory Identifier to be used in conjunction with > configurationPid. I thought a factory identifier was to take the place of > configurationPid + factory = true but that doesn’t appear to be the case. > > Scott > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev