> 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.
>> 
>>> 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

Reply via email to