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 <tim.w...@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 <massimobo...@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 <tim.w...@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 <massimobo...@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*
