These are absolutely not the same things!
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
> {….}
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
> 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 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
