Hi,
I agree, that's not possible. Now, you could think about using different
configurations. So the shared part is one OSGi configuration and each
"extension" is another OSGi configuration specific to your component.
A DS component can consume multiple configurations.
The additional advantage is that the shared part needs only to be
configured once. The disadvantage might be that this is now shared
between your components and they will use the exact same configuration
Regards
Carsten
Am 07.11.2018 um 18:07 schrieb João Assunção:
Hello Tim,
I understand that. I just assumed the default values provided in the AD
elements of the Metatype XML files would be used as defaults by
ConfigAdmin. I guess the Metatype information is used only for UI purposes.
I guess I will be forced to duplicate configuration attributes in my
configuration annotations. Using the approach suggested by Carsten I
would need to create the MetaType files by hand. At least I didn't found
a way to generate an OCD from two separate configuration annotations.
João Assunção
Email: [email protected] <mailto:[email protected]>
Mobile: +351 916968984
Phone: +351 211933149
Web: www.exploitsys.com <http://www.exploitsys.com>
On Wed, Nov 7, 2018 at 3:26 PM Tim Ward <[email protected]
<mailto:[email protected]>> wrote:
The @AttributeDefinition is a build time annotation, not a runtime
annotation. There is therefore no visibility of the annotation
values for DS to use at runtime. This also avoids your bundle from
being coupled to the meta type API just because it uses the annotations.
Best Regards,
Tim
On 7 Nov 2018, at 11:10, João Assunção via osgi-dev
<[email protected] <mailto:[email protected]>> wrote:
Hi Carsten,
Thank you for the clarification and the tip.
I assumed the framework would use the defaults provided
in @AttributeDefinition when using an interface for configuration.
Regards,
João Assunção
Email: [email protected]
<mailto:[email protected]>
Mobile: +351 916968984
Phone: +351 211933149
Web: www.exploitsys.com <http://www.exploitsys.com/>
On Wed, Nov 7, 2018 at 11:00 AM Carsten Ziegeler
<[email protected] <mailto:[email protected]>> wrote:
Hi,
no interfaces are not supported for configuration, only
annotations.
Main reason is the support of default values for configuration
properties.
But you can pass in more arguments into the activate method,
so instead
of having a base interface C and lets say two configuration
interface C1
and C2 inheriting from C, you specify three annotations C, C1
and C2
where C1 and C2 only have the additional properties.
In your activate method you can then have two arguments C and
C1 for one
component and C and C2 for the other component.
Regards
Carsten
Am 07.11.2018 um 11:53 schrieb João Assunção via osgi-dev:
> Hello all,
>
> I have two components where the configuration shares a
couple of
> attributes. To avoid duplication, and because Java doesn't
allow
> annotations to be extended, I changed the configuration
annotations to
> interfaces.
> When building, bnd-maven-plugin fails with the following
error message:
>
> Non annotation argument to lifecycle method with descriptor
>
> I checked the specs and @ObjectClassDefinition can be
applied to an
> interface type.
>
> Thank you
> João
>
> Email: [email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
> Mobile: +351 916968984
> Phone: +351 211933149
> Web: www.exploitsys.com <http://www.exploitsys.com/>
<http://www.exploitsys.com <http://www.exploitsys.com/>>
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected] <mailto:[email protected]>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected] <mailto:[email protected]>
_______________________________________________
OSGi Developer Mail List
[email protected] <mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
