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
Hi again,
Unfortunately, that will not work for me.
Thank you nevertheless.
Best regards,
João Assunção
Email: joao.assun...@exploitsys.com
Mobile: +351 916968984
Phone: +351 211933149
Web: www.exploitsys.com
On Wed, Nov 7, 2018 at 5:42 PM Carsten Ziegeler
wrote:
> Hi,
>
> I agree, that's
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: joao.assun...@exploitsys.com
Mobile: +351 916968984
Phone: +351 211933149
Web:
Remember that "groupId" and "artifactId" are Maven concepts.
Not all software is built with Maven and therefore not every OSGi bundle
has a groupId and artifactId. Nevertheless, OSGi requires all bundles to
have some kind of identity. This is what Bundle-SymbolicName give us.
Neil
On Wed, Nov
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:
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
Hi Ali,
On Wed, 2018-11-07 at 06:53 +0300, Ali Parmaksız via osgi-dev wrote:
> Hi all,
> This is a basic question. But i want to ask you why symbolic name is
> needed?
> Then i think that it is about bundle installation, bundle:install
> command
> is sometihng like that:
> bundle:install
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
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
