You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Massimo Bono <ma...@gmail.com> on 2019/12/17 17:30:39 UTC

Missing requirement of org.osgi.service.component

Hi,

I'm developing a bundle which provides an abstract class called
"AbstractBundle". Such class uses DS annotation over abstract methods, like:

@Deactivate
public abstract void deactivate();

This leads to the fact that the class imports classes from
"org.osgi.service.component". I want to declare this abstract class mainly
for allowing developers to automatically implements some important DS
methods and for documentation purposes.

The generated bundles has the correctly Import-Package entry
(org.osgi.service.component;version="[1.3,2)"). However, when I try to test
its installation in a "KarafTestSupport" derived class (where in the config
i install the SCR feature via:

KarafDistributionOption.features("standard", "scr")

karaf still complaints about the missing reference. here the error:

org.apache.felix.resolver.reason.ReasonException: Unable to resolve root:
missing requirement [root] osgi.identity; osgi.identity=FOO;
type=karaf.feature; version=0;
filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))"
[caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1]
osgi.identity; osgi.identity=FOO; type=osgi.bundle;
version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable to
resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))"]]

Note that I install the artifact exposing class AbstractBundle via a karaf
feature.

Am I doing something which is invalid?

Thanks for any kind reply

-- 
*Ing. Massimo Bono*

Re: Missing requirement of org.osgi.service.component

Posted by Massimo Bono <ma...@gmail.com>.
Ok, something is not right ( or I'm stupid).

by inspecting scr feature (feature:info scr) I obtain the following output:

Feature scr 4.2.7
Description:
  Declarative Service support
Feature has no configuration
Feature has no configuration files
Feature has no dependencies.
Feature contains followed bundles:
  mvn:org.osgi/org.osgi.util.function/1.0.0 start-level=30
  mvn:org.osgi/org.osgi.util.promise/1.0.0 start-level=30
  mvn:org.apache.felix/org.apache.felix.metatype/1.2.2 start-level=30
  mvn:org.apache.felix/org.apache.felix.scr/2.1.16 start-level=30
Feature contains followed conditionals:
Conditional(management) has no configuration
Conditional(management) has no configuration files
Conditional(management) has no dependencies.
Conditional(management) contains followed bundles:
  mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.2.7
start-level=30
Conditional(webconsole) has no configuration
Conditional(webconsole) has no configuration files
Conditional(webconsole) has no dependencies.
Conditional(webconsole) contains followed bundles:
  mvn:org.apache.felix/org.apache.felix.inventory/1.0.4 start-level=30
  mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.1.0
start-level=30
Conditional(bundle) has no configuration
Conditional(bundle) has no configuration files
Conditional(bundle) has no dependencies.
Conditional(bundle) contains followed bundles:
  mvn:org.apache.karaf.scr/org.apache.karaf.scr.state/4.2.7 start-level=30

in particular, "mvn:org.apache.felix/org.apache.felix.scr/2.1.16
start-level=30" is installed in my framework and by performing
"bundle:headers" I obtain an output which export package includes:

Export-Package =
org.apache.felix.scr.component;uses:=org.osgi.service.component;version=1.1.0,
org.apache.felix.scr.info;version=1.0.0,
org.osgi.service.component;uses:=org.osgi.framework;version=1.4,
org.osgi.service.component.runtime;uses:="org.osgi.framework,org.osgi.service.component.runtime.dto,org.osgi.util.promise";version=1.4,
org.osgi.service.component.runtime.dto;uses:="org.osgi.dto,org.osgi.framework.dto";version=1.4

hence scr correctly expose org.osgi.servicve.components (even version 1.4!).

I also notice that if i perform these steps on a normal karaf instance (via
shell) " org.osgi.service.component" is actually found.
*It seems the problem is present only when performing automated testing
with Pax-Exam. -.-"*
Forget performing annotation inheritance. Any ideas on how to solve the
missing requirement of scr?

BTW I have apache karaf 4.2.7


Il giorno mar 17 dic 2019 alle ore 19:08 Tim Ward <ti...@paremus.com> ha
scritto:

> I genuinely though karaf supported DS1.3 specification (in constrast to
> the recent DS 1.4, which it shouldn't be supported yet): do you know the
> link where the DS support is publicly announced? Thanks
>
>
> I’ll leave this to someone more expert in Karaf releases than I. My aim
> was simply to turn the resolver output into plain English (it’s not
> amazingly human readable).
>
> The exact failure is that nobody is providing the
> org.osgi.service.component package (the one containing ComponentContext) at
> a version greater than or equal to 1.3, but loader than 2.0. This is
> required for any compliant DS implementation at version 1.3 or 1.4, hence
> my statement that the Karaf you’re deploying into doesn’t support DS (if it
> did it would have the package). You may be able to fix this by referencing
> another feature to deploy DS and add the support to your Karaf, but there
> are issues in Karaf if you end up with two DS implementations running at
> the same time (and there really should be one deployed by default!).
>
> I hope this helps.
>
> Tim
>
> Sent from my iPhone
>
> On 17 Dec 2019, at 17:51, Massimo Bono <ma...@gmail.com> wrote:
>
> Hi,
>
> > Long story short, annotation inheritance is something that you are
> strongly discouraged from doing.
>
> ok, perfect.
>
> > This error is actually not to do with annotation inheritance. Instead
> the issue is that you’re trying to use DS 1.3, but Karaf doesn’t support it.
>
> I genuinely though karaf supported DS1.3 specification (in constrast to
> the recent DS 1.4, which it shouldn't be supported yet): do you know the
> link where the DS support is publicly announced? Thanks
>
> Il giorno mar 17 dic 2019 alle ore 18:39 Tim Ward <ti...@paremus.com>
> ha scritto:
>
>> Hi Massimo,
>>
>> Am I doing something which is invalid?
>>
>>
>> Long story short, annotation inheritance is something that you are
>> strongly discouraged from doing.
>>
>> The DS annotations are not designed to be inherited by child classes,
>> technically this is a violation of encapsulation because the DS runtime is
>> reflectively calling fields/methods on a super type which is defined in
>> another bundle. As DS is allowed to (and normally does) operate on default
>> or private visibility members this means that you can end up referencing
>> the private internals of another bundle (the one holding the super type) in
>> another bundle (the one holding the component). This can then break at
>> runtime if you wire to an updated version of the super type which has (for
>> example) changed the name of a private field.
>>
>> If you do want to use inherited annotations across bundles (not a good
>> idea) then you can do so by using bnd configuration
>> <https://bnd.bndtools.org/instructions/dsannotations-options.html>.
>>
>> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root:
>> missing requirement [root] osgi.identity; osgi.identity=FOO;
>> type=karaf.feature; version=0;
>> filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))"
>> [caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1]
>> osgi.identity; osgi.identity=FOO; type=osgi.bundle;
>> version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable to
>> resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.wiring.package;
>> filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))”]]
>>
>>
>> This error is actually not to do with annotation inheritance. Instead the
>> issue is that you’re trying to use DS 1.3, but Karaf doesn’t support it.
>>
>> Tim
>>
>>
>> On 17 Dec 2019, at 17:30, Massimo Bono <ma...@gmail.com> wrote:
>>
>> Hi,
>>
>> I'm developing a bundle which provides an abstract class called
>> "AbstractBundle". Such class uses DS annotation over abstract methods, like:
>>
>> @Deactivate
>> public abstract void deactivate();
>>
>> This leads to the fact that the class imports classes from
>> "org.osgi.service.component". I want to declare this abstract class mainly
>> for allowing developers to automatically implements some important DS
>> methods and for documentation purposes.
>>
>> The generated bundles has the correctly Import-Package entry
>> (org.osgi.service.component;version="[1.3,2)"). However, when I try to test
>> its installation in a "KarafTestSupport" derived class (where in the config
>> i install the SCR feature via:
>>
>> KarafDistributionOption.features("standard", "scr")
>>
>> karaf still complaints about the missing reference. here the error:
>>
>> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root:
>> missing requirement [root] osgi.identity; osgi.identity=FOO;
>> type=karaf.feature; version=0;
>> filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))"
>> [caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1]
>> osgi.identity; osgi.identity=FOO; type=osgi.bundle;
>> version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable to
>> resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.wiring.package;
>> filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))"]]
>>
>> Note that I install the artifact exposing class AbstractBundle via a
>> karaf feature.
>>
>> Am I doing something which is invalid?
>>
>> Thanks for any kind reply
>>
>> --
>> *Ing. Massimo Bono*
>>
>>
>>
>
> --
> *Ing. Massimo Bono*
>
>

-- 
*Ing. Massimo Bono*

Re: Missing requirement of org.osgi.service.component

Posted by Tim Ward <ti...@paremus.com>.
> I genuinely though karaf supported DS1.3 specification (in constrast to the recent DS 1.4, which it shouldn't be supported yet): do you know the link where the DS support is publicly announced? Thanks

I’ll leave this to someone more expert in Karaf releases than I. My aim was simply to turn the resolver output into plain English (it’s not amazingly human readable). 

The exact failure is that nobody is providing the org.osgi.service.component package (the one containing ComponentContext) at a version greater than or equal to 1.3, but loader than 2.0. This is required for any compliant DS implementation at version 1.3 or 1.4, hence my statement that the Karaf you’re deploying into doesn’t support DS (if it did it would have the package). You may be able to fix this by referencing another feature to deploy DS and add the support to your Karaf, but there are issues in Karaf if you end up with two DS implementations running at the same time (and there really should be one deployed by default!). 

I hope this helps. 

Tim

Sent from my iPhone

> On 17 Dec 2019, at 17:51, Massimo Bono <ma...@gmail.com> wrote:
> 
> Hi,
> 
> > Long story short, annotation inheritance is something that you are strongly discouraged from doing.
> 
> ok, perfect. 
> 
> > This error is actually not to do with annotation inheritance. Instead the issue is that you’re trying to use DS 1.3, but Karaf doesn’t support it.
> 
> I genuinely though karaf supported DS1.3 specification (in constrast to the recent DS 1.4, which it shouldn't be supported yet): do you know the link where the DS support is publicly announced? Thanks
> 
>> Il giorno mar 17 dic 2019 alle ore 18:39 Tim Ward <ti...@paremus.com> ha scritto:
>> Hi Massimo,
>> 
>>> Am I doing something which is invalid?
>> 
>> Long story short, annotation inheritance is something that you are strongly discouraged from doing.
>> 
>> The DS annotations are not designed to be inherited by child classes, technically this is a violation of encapsulation because the DS runtime is reflectively calling fields/methods on a super type which is defined in another bundle. As DS is allowed to (and normally does) operate on default or private visibility members this means that you can end up referencing the private internals of another bundle (the one holding the super type) in another bundle (the one holding the component). This can then break at runtime if you wire to an updated version of the super type which has (for example) changed the name of a private field.
>> 
>> If you do want to use inherited annotations across bundles (not a good idea) then you can do so by using bnd configuration.
>> 
>>> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=FOO; type=karaf.feature; version=0; filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))" [caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.identity; osgi.identity=FOO; type=osgi.bundle; version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))”]]
>> 
>> This error is actually not to do with annotation inheritance. Instead the issue is that you’re trying to use DS 1.3, but Karaf doesn’t support it.
>> 
>> Tim
>> 
>> 
>>> On 17 Dec 2019, at 17:30, Massimo Bono <ma...@gmail.com> wrote:
>>> 
>>> Hi, 
>>> 
>>> I'm developing a bundle which provides an abstract class called "AbstractBundle". Such class uses DS annotation over abstract methods, like:
>>> 
>>> @Deactivate
>>> public abstract void deactivate();
>>> 
>>> This leads to the fact that the class imports classes from "org.osgi.service.component". I want to declare this abstract class mainly for allowing developers to automatically implements some important DS methods and for documentation purposes.
>>> 
>>> The generated bundles has the correctly Import-Package entry (org.osgi.service.component;version="[1.3,2)"). However, when I try to test its installation in a "KarafTestSupport" derived class (where in the config i install the SCR feature via:
>>> 
>>> KarafDistributionOption.features("standard", "scr")
>>> 
>>> karaf still complaints about the missing reference. here the error:
>>> 
>>> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=FOO; type=karaf.feature; version=0; filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))" [caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.identity; osgi.identity=FOO; type=osgi.bundle; version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))"]]
>>> 
>>> Note that I install the artifact exposing class AbstractBundle via a karaf feature.
>>> 
>>> Am I doing something which is invalid?
>>> 
>>> Thanks for any kind reply
>>> 
>>> -- 
>>> Ing. Massimo Bono
>> 
> 
> 
> -- 
> Ing. Massimo Bono

Re: Missing requirement of org.osgi.service.component

Posted by Massimo Bono <ma...@gmail.com>.
Hi JB,

by doing feature:info scr, I have obtained:

Feature scr 4.2.7
Description:
  Declarative Service support
Feature has no configuration
Feature has no configuration files
Feature has no dependencies.
Feature contains followed bundles:
  mvn:org.osgi/org.osgi.util.function/1.0.0 start-level=30
  mvn:org.osgi/org.osgi.util.promise/1.0.0 start-level=30
  mvn:org.apache.felix/org.apache.felix.metatype/1.2.2 start-level=30
  mvn:org.apache.felix/org.apache.felix.scr/2.1.16 start-level=30
Feature contains followed conditionals:
Conditional(management) has no configuration
Conditional(management) has no configuration files
Conditional(management) has no dependencies.
Conditional(management) contains followed bundles:
  mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.2.7
start-level=30
Conditional(webconsole) has no configuration
Conditional(webconsole) has no configuration files
Conditional(webconsole) has no dependencies.
Conditional(webconsole) contains followed bundles:
  mvn:org.apache.felix/org.apache.felix.inventory/1.0.4 start-level=30
  mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.1.0
start-level=30
Conditional(bundle) has no configuration
Conditional(bundle) has no configuration files
Conditional(bundle) has no dependencies.
Conditional(bundle) contains followed bundles:
  mvn:org.apache.karaf.scr/org.apache.karaf.scr.state/4.2.7 start-level=30

Seems like scr version is 4.2.7.

Again I want to highlight the fact that this missing requirement happens
only when performing automated testing. When installing the bundle, I can
detect that installing and starting the feature "scr" does solve the
requirement (since "bundle:diag" shows no unsatisfied requirements from scr
after the feature is installed).

Il giorno mar 17 dic 2019 alle ore 22:07 Jean-Baptiste Onofré <
jb@nanthrax.net> ha scritto:

> Hi,
>
> it's supported. If you take a look on the SCR bundle installed, it
> should be good.
>
> Do you use a different SCR version ? Can you check the scr feature
> version installed ?
>
> Regards
> JB
>
> On 17/12/2019 18:51, Massimo Bono wrote:
> > Hi,
> >
> >> Long story short, annotation inheritance is something that you are
> strongly discouraged from doing.
> >
> > ok, perfect.
> >
> >> This error is actually not to do with annotation inheritance. Instead
> > the issue is that you’re trying to use DS 1.3, but Karaf doesn’t support
> it.
> >
> > I genuinely though karaf supported DS1.3 specification (in constrast to
> > the recent DS 1.4, which it shouldn't be supported yet): do you know the
> > link where the DS support is publicly announced? Thanks
> >
> > Il giorno mar 17 dic 2019 alle ore 18:39 Tim Ward <tim.ward@paremus.com
> > <ma...@paremus.com>> ha scritto:
> >
> >     Hi Massimo,
> >
> >>     Am I doing something which is invalid?
> >
> >     Long story short, annotation inheritance is something that you are
> >     strongly discouraged from doing.
> >
> >     The DS annotations are not designed to be inherited by child
> >     classes, technically this is a violation of encapsulation because
> >     the DS runtime is reflectively calling fields/methods on a super
> >     type which is defined in another bundle. As DS is allowed to (and
> >     normally does) operate on default or private visibility members this
> >     means that you can end up referencing the private internals of
> >     another bundle (the one holding the super type) in another bundle
> >     (the one holding the component). This can then break at runtime if
> >     you wire to an updated version of the super type which has (for
> >     example) changed the name of a private field.
> >
> >     If you do want to use inherited annotations across bundles (not a
> >     good idea) then you can do so by using bnd configuration
> >     <https://bnd.bndtools.org/instructions/dsannotations-options.html>.
> >
> >>     org.apache.felix.resolver.reason.ReasonException: Unable to
> >>     resolve root: missing requirement [root] osgi.identity;
> >>     osgi.identity=FOO; type=karaf.feature; version=0;
> >>     filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))"
> >>     [caused by: Unable to resolve FOO/0.0.1: missing requirement
> >>     [FOO/0.0.1] osgi.identity; osgi.identity=FOO; type=osgi.bundle;
> >>     version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable
> >>     to resolve FOO/0.0.1: missing requirement [FOO/0.0.1]
> >>     osgi.wiring.package;
> >>
>  filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))”]]
> >
> >     This error is actually not to do with annotation inheritance.
> >     Instead the issue is that you’re trying to use DS 1.3, but Karaf
> >     doesn’t support it.
> >
> >     Tim
> >
> >
> >>     On 17 Dec 2019, at 17:30, Massimo Bono <massimobono1@gmail.com
> >>     <ma...@gmail.com>> wrote:
> >>
> >>     Hi,
> >>
> >>     I'm developing a bundle which provides an abstract class called
> >>     "AbstractBundle". Such class uses DS annotation over abstract
> >>     methods, like:
> >>
> >>     @Deactivate
> >>     public abstract void deactivate();
> >>
> >>     This leads to the fact that the class imports classes from
> >>     "org.osgi.service.component". I want to declare this abstract
> >>     class mainly for allowing developers to automatically implements
> >>     some important DS methods and for documentation purposes.
> >>
> >>     The generated bundles has the correctly Import-Package entry
> >>     (org.osgi.service.component;version="[1.3,2)"). However, when I
> >>     try to test its installation in a "KarafTestSupport" derived class
> >>     (where in the config i install the SCR feature via:
> >>
> >>     KarafDistributionOption.features("standard", "scr")
> >>
> >>     karaf still complaints about the missing reference. here the error:
> >>
> >>     org.apache.felix.resolver.reason.ReasonException: Unable to
> >>     resolve root: missing requirement [root] osgi.identity;
> >>     osgi.identity=FOO; type=karaf.feature; version=0;
> >>     filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))"
> >>     [caused by: Unable to resolve FOO/0.0.1: missing requirement
> >>     [FOO/0.0.1] osgi.identity; osgi.identity=FOO; type=osgi.bundle;
> >>     version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable
> >>     to resolve FOO/0.0.1: missing requirement [FOO/0.0.1]
> >>     osgi.wiring.package;
> >>
>  filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))"]]
> >>
> >>     Note that I install the artifact exposing class AbstractBundle via
> >>     a karaf feature.
> >>
> >>     Am I doing something which is invalid?
> >>
> >>     Thanks for any kind reply
> >>
> >>     --
> >>     *Ing. Massimo Bono*
> >
> >
> >
> > --
> > *Ing. Massimo Bono*
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


-- 
*Ing. Massimo Bono*

Re: Missing requirement of org.osgi.service.component

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,

it's supported. If you take a look on the SCR bundle installed, it
should be good.

Do you use a different SCR version ? Can you check the scr feature
version installed ?

Regards
JB

On 17/12/2019 18:51, Massimo Bono wrote:
> Hi,
> 
>> Long story short, annotation inheritance is something that you are strongly discouraged from doing.
> 
> ok, perfect.
> 
>> This error is actually not to do with annotation inheritance. Instead
> the issue is that you’re trying to use DS 1.3, but Karaf doesn’t support it.
> 
> I genuinely though karaf supported DS1.3 specification (in constrast to
> the recent DS 1.4, which it shouldn't be supported yet): do you know the
> link where the DS support is publicly announced? Thanks
> 
> Il giorno mar 17 dic 2019 alle ore 18:39 Tim Ward <tim.ward@paremus.com
> <ma...@paremus.com>> ha scritto:
> 
>     Hi Massimo,
> 
>>     Am I doing something which is invalid?
> 
>     Long story short, annotation inheritance is something that you are
>     strongly discouraged from doing.
> 
>     The DS annotations are not designed to be inherited by child
>     classes, technically this is a violation of encapsulation because
>     the DS runtime is reflectively calling fields/methods on a super
>     type which is defined in another bundle. As DS is allowed to (and
>     normally does) operate on default or private visibility members this
>     means that you can end up referencing the private internals of
>     another bundle (the one holding the super type) in another bundle
>     (the one holding the component). This can then break at runtime if
>     you wire to an updated version of the super type which has (for
>     example) changed the name of a private field.
> 
>     If you do want to use inherited annotations across bundles (not a
>     good idea) then you can do so by using bnd configuration
>     <https://bnd.bndtools.org/instructions/dsannotations-options.html>.
> 
>>     org.apache.felix.resolver.reason.ReasonException: Unable to
>>     resolve root: missing requirement [root] osgi.identity;
>>     osgi.identity=FOO; type=karaf.feature; version=0;
>>     filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))"
>>     [caused by: Unable to resolve FOO/0.0.1: missing requirement
>>     [FOO/0.0.1] osgi.identity; osgi.identity=FOO; type=osgi.bundle;
>>     version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable
>>     to resolve FOO/0.0.1: missing requirement [FOO/0.0.1]
>>     osgi.wiring.package;
>>     filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))”]]
> 
>     This error is actually not to do with annotation inheritance.
>     Instead the issue is that you’re trying to use DS 1.3, but Karaf
>     doesn’t support it.
> 
>     Tim
> 
> 
>>     On 17 Dec 2019, at 17:30, Massimo Bono <massimobono1@gmail.com
>>     <ma...@gmail.com>> wrote:
>>
>>     Hi,
>>
>>     I'm developing a bundle which provides an abstract class called
>>     "AbstractBundle". Such class uses DS annotation over abstract
>>     methods, like:
>>
>>     @Deactivate
>>     public abstract void deactivate();
>>
>>     This leads to the fact that the class imports classes from
>>     "org.osgi.service.component". I want to declare this abstract
>>     class mainly for allowing developers to automatically implements
>>     some important DS methods and for documentation purposes.
>>
>>     The generated bundles has the correctly Import-Package entry
>>     (org.osgi.service.component;version="[1.3,2)"). However, when I
>>     try to test its installation in a "KarafTestSupport" derived class
>>     (where in the config i install the SCR feature via:
>>
>>     KarafDistributionOption.features("standard", "scr")
>>
>>     karaf still complaints about the missing reference. here the error:
>>
>>     org.apache.felix.resolver.reason.ReasonException: Unable to
>>     resolve root: missing requirement [root] osgi.identity;
>>     osgi.identity=FOO; type=karaf.feature; version=0;
>>     filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))"
>>     [caused by: Unable to resolve FOO/0.0.1: missing requirement
>>     [FOO/0.0.1] osgi.identity; osgi.identity=FOO; type=osgi.bundle;
>>     version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable
>>     to resolve FOO/0.0.1: missing requirement [FOO/0.0.1]
>>     osgi.wiring.package;
>>     filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))"]]
>>
>>     Note that I install the artifact exposing class AbstractBundle via
>>     a karaf feature.
>>
>>     Am I doing something which is invalid?
>>
>>     Thanks for any kind reply
>>
>>     -- 
>>     *Ing. Massimo Bono*
> 
> 
> 
> -- 
> *Ing. Massimo Bono*

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Missing requirement of org.osgi.service.component

Posted by Massimo Bono <ma...@gmail.com>.
Hi,

> Long story short, annotation inheritance is something that you are
strongly discouraged from doing.

ok, perfect.

> This error is actually not to do with annotation inheritance. Instead the
issue is that you’re trying to use DS 1.3, but Karaf doesn’t support it.

I genuinely though karaf supported DS1.3 specification (in constrast to the
recent DS 1.4, which it shouldn't be supported yet): do you know the link
where the DS support is publicly announced? Thanks

Il giorno mar 17 dic 2019 alle ore 18:39 Tim Ward <ti...@paremus.com> ha
scritto:

> Hi Massimo,
>
> Am I doing something which is invalid?
>
>
> Long story short, annotation inheritance is something that you are
> strongly discouraged from doing.
>
> The DS annotations are not designed to be inherited by child classes,
> technically this is a violation of encapsulation because the DS runtime is
> reflectively calling fields/methods on a super type which is defined in
> another bundle. As DS is allowed to (and normally does) operate on default
> or private visibility members this means that you can end up referencing
> the private internals of another bundle (the one holding the super type) in
> another bundle (the one holding the component). This can then break at
> runtime if you wire to an updated version of the super type which has (for
> example) changed the name of a private field.
>
> If you do want to use inherited annotations across bundles (not a good
> idea) then you can do so by using bnd configuration
> <https://bnd.bndtools.org/instructions/dsannotations-options.html>.
>
> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root:
> missing requirement [root] osgi.identity; osgi.identity=FOO;
> type=karaf.feature; version=0;
> filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))"
> [caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1]
> osgi.identity; osgi.identity=FOO; type=osgi.bundle;
> version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable to
> resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))”]]
>
>
> This error is actually not to do with annotation inheritance. Instead the
> issue is that you’re trying to use DS 1.3, but Karaf doesn’t support it.
>
> Tim
>
>
> On 17 Dec 2019, at 17:30, Massimo Bono <ma...@gmail.com> wrote:
>
> Hi,
>
> I'm developing a bundle which provides an abstract class called
> "AbstractBundle". Such class uses DS annotation over abstract methods, like:
>
> @Deactivate
> public abstract void deactivate();
>
> This leads to the fact that the class imports classes from
> "org.osgi.service.component". I want to declare this abstract class mainly
> for allowing developers to automatically implements some important DS
> methods and for documentation purposes.
>
> The generated bundles has the correctly Import-Package entry
> (org.osgi.service.component;version="[1.3,2)"). However, when I try to test
> its installation in a "KarafTestSupport" derived class (where in the config
> i install the SCR feature via:
>
> KarafDistributionOption.features("standard", "scr")
>
> karaf still complaints about the missing reference. here the error:
>
> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root:
> missing requirement [root] osgi.identity; osgi.identity=FOO;
> type=karaf.feature; version=0;
> filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))"
> [caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1]
> osgi.identity; osgi.identity=FOO; type=osgi.bundle;
> version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable to
> resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))"]]
>
> Note that I install the artifact exposing class AbstractBundle via a karaf
> feature.
>
> Am I doing something which is invalid?
>
> Thanks for any kind reply
>
> --
> *Ing. Massimo Bono*
>
>
>

-- 
*Ing. Massimo Bono*

Re: Missing requirement of org.osgi.service.component

Posted by Tim Ward <ti...@paremus.com>.
Hi Massimo,

> Am I doing something which is invalid?

Long story short, annotation inheritance is something that you are strongly discouraged from doing.

The DS annotations are not designed to be inherited by child classes, technically this is a violation of encapsulation because the DS runtime is reflectively calling fields/methods on a super type which is defined in another bundle. As DS is allowed to (and normally does) operate on default or private visibility members this means that you can end up referencing the private internals of another bundle (the one holding the super type) in another bundle (the one holding the component). This can then break at runtime if you wire to an updated version of the super type which has (for example) changed the name of a private field.

If you do want to use inherited annotations across bundles (not a good idea) then you can do so by using bnd configuration <https://bnd.bndtools.org/instructions/dsannotations-options.html>.

> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=FOO; type=karaf.feature; version=0; filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))" [caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.identity; osgi.identity=FOO; type=osgi.bundle; version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))”]]

This error is actually not to do with annotation inheritance. Instead the issue is that you’re trying to use DS 1.3, but Karaf doesn’t support it.

Tim


> On 17 Dec 2019, at 17:30, Massimo Bono <ma...@gmail.com> wrote:
> 
> Hi, 
> 
> I'm developing a bundle which provides an abstract class called "AbstractBundle". Such class uses DS annotation over abstract methods, like:
> 
> @Deactivate
> public abstract void deactivate();
> 
> This leads to the fact that the class imports classes from "org.osgi.service.component". I want to declare this abstract class mainly for allowing developers to automatically implements some important DS methods and for documentation purposes.
> 
> The generated bundles has the correctly Import-Package entry (org.osgi.service.component;version="[1.3,2)"). However, when I try to test its installation in a "KarafTestSupport" derived class (where in the config i install the SCR feature via:
> 
> KarafDistributionOption.features("standard", "scr")
> 
> karaf still complaints about the missing reference. here the error:
> 
> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=FOO; type=karaf.feature; version=0; filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))" [caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.identity; osgi.identity=FOO; type=osgi.bundle; version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))"]]
> 
> Note that I install the artifact exposing class AbstractBundle via a karaf feature.
> 
> Am I doing something which is invalid?
> 
> Thanks for any kind reply
> 
> -- 
> Ing. Massimo Bono