OSGi service and component

Forum|Forum|8 years ago
October 24, 2017
11 replies
8625 views

Hi All,

I have created 1 interface called - Interface A and I have one implementation class called: Class B

So, Class B is implementing Interface A . After deployment of OSGI bundle I could see in /system/console/bundles -

Service ID 10437 Types: Interface A

Component Name: Class B

Component ID: 3665 (Class B)

Now, I have created 1 more service called: Class C which is extending Class B , but after deployment I am not getting similar information for Class C.

Here, Component B and component C both are in active state. To understand the relation in between Service and component I have done one small changes -

Remove - Class C extends Class B

Use - Class C implements interface A and now I can see -

Service ID 10437 Types: Interface A

Component Name: Class C

Component ID: 3663 (Class C)

Is It not good idea if I follow below approach?

Class B implements Interface

Class C extends Class B

Here, I am thinking from the service design point of view.

I am using AEM 6.3 with archtype 11 and I have used org.osgi.service.component.annotations.Component and org.apache.felix.scr.annotations.Service.

Please correct my understanding.

Thanks

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

Best answer by joerghoh

Hi,

the problem lies in the fact, that SCR is not designed in that way. Inheriting from a class (which is also a component) does not inherit SCR annotations / definitions.

If you want to use inheritance to have a lot of similar services implementing the same interface, you could have an AbstractComponent B (look the SCR documentation for this) implementing the interface A, and then making Component C and D extending B. In that case the annotations (including the references) for all references in B should be usable in C and D as well.

On the other hand I have rarely seen this case actually implemented. I think that many very similar services implementing the same interface show a problematic software design.

Jörg