(You) 6 Years Ago [...] Another option is to use different ReferenceCardinality, ReferencePolicy and ReferencePolicyOption values (see my blog post on annotations, specifically the section on the @Reference annotation).... [...] Read More Please sign in to reply. Reply as... Cancel
Geert van der Ploeg 6 Years Ago Thanks David for the insights, especially the rules about having @Reference annotation on concrete subclasses was helpful.On a later occasion I stumbled upon a discussion which puts this 'limitation' in wider perspective, with Peter Kriens's opinion:https://groups.google.com/d/msg/bndtools-users/LI2YyFjwZNY/qymOS6YXzBUJEssentially he says he prevented inheritance support for DI because it creates tighter coupling between classes in a hierarchy, and saving only a tiny bit of duplication.-Geert Please sign in to reply. Reply as... Cancel David H Nebinger Geert van der Ploeg 6 Years Ago - Edited While I do respect his position, I'd call bullshit.As soon as you subclass, there is inherently a "tight coupling", and that's the intent. I mean, you won't go to your Animal heirarchy and subclass Cat to make a Fish class; if you subclass it is because you are coupling yourself to the implementation details of the superclass.And worse, when you don't necessarily control the superclasses, you can easily get hamstrung. In another blog post I remember talking about subclassing a Liferay class (I think an MVCActionCommand implementation) where the superclass had @Reference right on a private variable declaration. As a subclass, I had to not only mirror the @Reference on a setter method but I also had to use reflection to get access to the superclass field to inject the reference.It's easy to tear apart most of his arguments, actually. "If you subclass, you must know the class hierarchy", well, duh, isn't that true whether you're doing OSGi or not? Same is true for the "brittle" statement, the "changing superclass can break subclasses", etc. We've seen all of this in Liferay when no annotations or OSGi were part of the picture. That, after all, is the nature of inheritance. When you subclass, you are doing so because you want the bulk of the functionality and, yes, dependencies of the superclass - you might be overriding all or part of that implementation, but that is the subclasser's prerogative.Now of course the "bullshit" thing is my own opinion, and it is a reflection of my pragmatism and reflection of real-world situations, and it discards the purity one can have when dealing solely with theory. So while Peter is maybe absolutely right in theory, he ends up being wrong in reality.Personally I think the real reason it is not supported is because honestly there are challenges that would be difficult to overcome, such as how subclasses could change @Reference annotations - if the super class used a generic @Reference but subclass used a more specific filter, how would that be resolved. Or how would a subclass change the cardinality or policy of a superclass. Also how would a subclass "remove" an @Reference dependency that it didn't need or want OSGi to stop loading the component if not satisfied. I get that these would be hard edge cases to solve, but I would have respected a response saying it was easier to discard reference inheritance than it was to solve these more difficult concerns. Please sign in to reply. Reply as... Cancel Satyanarayana kolliboyin David H Nebinger 3 Years Ago - Edited Hi David, First of all Thank you to post very useful Information. You clearly rolled out that "@Reference annotations are going to be ignored in non-components, and in fact they are also ignored in subclasses too". But, I have found @Reference usage in the abstract classe is com.liferay.users.admin.web.internal.frontend.taglib.servlet.taglib.BaseUserScreenNavigationEntry.java puzzling is it working or not there? But, when I am implementing , getting as null for all @Reference class objects in the abstract class. Please sign in to reply. Reply as... Cancel David H Nebinger Satyanarayana kolliboyin 3 Years Ago - Edited A new directive was added to BND, "-dsannotations-options: inherit". When placed in the bnd.bnd file, any @Reference in superclasses will also be processed. When this blog was published, that directive did not yet exist (or at least I was unaware of it if it did). Please sign in to reply. Reply as... Cancel Satyanarayana kolliboyin David H Nebinger 3 Years Ago - Edited Thank you David, For your time. Yes after placing this new directive "-dsannotations-options:inherit" under bnd.bnd then @Reference in non-concrete classes also injecting. Please sign in to reply. Reply as... Cancel
David H Nebinger Geert van der Ploeg 6 Years Ago - Edited While I do respect his position, I'd call bullshit.As soon as you subclass, there is inherently a "tight coupling", and that's the intent. I mean, you won't go to your Animal heirarchy and subclass Cat to make a Fish class; if you subclass it is because you are coupling yourself to the implementation details of the superclass.And worse, when you don't necessarily control the superclasses, you can easily get hamstrung. In another blog post I remember talking about subclassing a Liferay class (I think an MVCActionCommand implementation) where the superclass had @Reference right on a private variable declaration. As a subclass, I had to not only mirror the @Reference on a setter method but I also had to use reflection to get access to the superclass field to inject the reference.It's easy to tear apart most of his arguments, actually. "If you subclass, you must know the class hierarchy", well, duh, isn't that true whether you're doing OSGi or not? Same is true for the "brittle" statement, the "changing superclass can break subclasses", etc. We've seen all of this in Liferay when no annotations or OSGi were part of the picture. That, after all, is the nature of inheritance. When you subclass, you are doing so because you want the bulk of the functionality and, yes, dependencies of the superclass - you might be overriding all or part of that implementation, but that is the subclasser's prerogative.Now of course the "bullshit" thing is my own opinion, and it is a reflection of my pragmatism and reflection of real-world situations, and it discards the purity one can have when dealing solely with theory. So while Peter is maybe absolutely right in theory, he ends up being wrong in reality.Personally I think the real reason it is not supported is because honestly there are challenges that would be difficult to overcome, such as how subclasses could change @Reference annotations - if the super class used a generic @Reference but subclass used a more specific filter, how would that be resolved. Or how would a subclass change the cardinality or policy of a superclass. Also how would a subclass "remove" an @Reference dependency that it didn't need or want OSGi to stop loading the component if not satisfied. I get that these would be hard edge cases to solve, but I would have respected a response saying it was easier to discard reference inheritance than it was to solve these more difficult concerns. Please sign in to reply. Reply as... Cancel Satyanarayana kolliboyin David H Nebinger 3 Years Ago - Edited Hi David, First of all Thank you to post very useful Information. You clearly rolled out that "@Reference annotations are going to be ignored in non-components, and in fact they are also ignored in subclasses too". But, I have found @Reference usage in the abstract classe is com.liferay.users.admin.web.internal.frontend.taglib.servlet.taglib.BaseUserScreenNavigationEntry.java puzzling is it working or not there? But, when I am implementing , getting as null for all @Reference class objects in the abstract class. Please sign in to reply. Reply as... Cancel David H Nebinger Satyanarayana kolliboyin 3 Years Ago - Edited A new directive was added to BND, "-dsannotations-options: inherit". When placed in the bnd.bnd file, any @Reference in superclasses will also be processed. When this blog was published, that directive did not yet exist (or at least I was unaware of it if it did). Please sign in to reply. Reply as... Cancel Satyanarayana kolliboyin David H Nebinger 3 Years Ago - Edited Thank you David, For your time. Yes after placing this new directive "-dsannotations-options:inherit" under bnd.bnd then @Reference in non-concrete classes also injecting. Please sign in to reply. Reply as... Cancel
Satyanarayana kolliboyin David H Nebinger 3 Years Ago - Edited Hi David, First of all Thank you to post very useful Information. You clearly rolled out that "@Reference annotations are going to be ignored in non-components, and in fact they are also ignored in subclasses too". But, I have found @Reference usage in the abstract classe is com.liferay.users.admin.web.internal.frontend.taglib.servlet.taglib.BaseUserScreenNavigationEntry.java puzzling is it working or not there? But, when I am implementing , getting as null for all @Reference class objects in the abstract class. Please sign in to reply. Reply as... Cancel David H Nebinger Satyanarayana kolliboyin 3 Years Ago - Edited A new directive was added to BND, "-dsannotations-options: inherit". When placed in the bnd.bnd file, any @Reference in superclasses will also be processed. When this blog was published, that directive did not yet exist (or at least I was unaware of it if it did). Please sign in to reply. Reply as... Cancel Satyanarayana kolliboyin David H Nebinger 3 Years Ago - Edited Thank you David, For your time. Yes after placing this new directive "-dsannotations-options:inherit" under bnd.bnd then @Reference in non-concrete classes also injecting. Please sign in to reply. Reply as... Cancel
David H Nebinger Satyanarayana kolliboyin 3 Years Ago - Edited A new directive was added to BND, "-dsannotations-options: inherit". When placed in the bnd.bnd file, any @Reference in superclasses will also be processed. When this blog was published, that directive did not yet exist (or at least I was unaware of it if it did). Please sign in to reply. Reply as... Cancel Satyanarayana kolliboyin David H Nebinger 3 Years Ago - Edited Thank you David, For your time. Yes after placing this new directive "-dsannotations-options:inherit" under bnd.bnd then @Reference in non-concrete classes also injecting. Please sign in to reply. Reply as... Cancel
Satyanarayana kolliboyin David H Nebinger 3 Years Ago - Edited Thank you David, For your time. Yes after placing this new directive "-dsannotations-options:inherit" under bnd.bnd then @Reference in non-concrete classes also injecting. Please sign in to reply. Reply as... Cancel
David Ilechukwu 6 Years Ago Greetings Dave - you've managed to write an excellent, comprehensive and very needful article all-in-one! I'm trying to create osgi component exactly like the ImageTool component in Liferay 7. I've implemented my ImageDisplayUtil class and ImageDisplay interface both in util folder in api module and I've also implented my ImageDisplayImpl class in service module. But I notice that Liferay doesnt use the @Component, @Reference annotations for the ImageTool and ImageToolImpl classes (just uses @ProviderType) - & yet these classes work. In my own case - I'm getting a nullpointer exception when trying to get a reference of the interface from the util. I haven't used the @Component or @Reference either. But how come Liferay core classes wo4k without thesr anotts and mine doesnt?Greetings Dave - you've managed to write an excellent, comprehensive and very needful article all-in-one! I'm trying to create osgi component exactly like the ImageTool component in Liferay 7. I've implemented my ImageDisplayUtil and ImageDisplay Please sign in to reply. Reply as... Cancel
David Ilechukwu 6 Years Ago Greetings Dave - you've managed to write an excellent, comprehensive and very needful article all-in-one! I'm trying to create osgi component exactly like the ImageTool component in Liferay 7. I've implemented my ImageDisplayUtil class and ImageDisplay interface both in util folder in api module and I've also implented my ImageDisplayImpl class in service module. But I notice that Liferay doesnt use the @Component, @Reference annotations for the ImageTool and ImageToolImpl classes (just uses @ProviderType) - & yet these classes work. In my own case - I'm getting a nullpointer exception when trying to get a reference of the interface from the util. I haven't used the @Component or @Reference either. But how come Liferay core classes wo4k without thesr anotts and mine doesnt?Greetings Dave - you've managed to write an excellent, comprehensive and very needful article all-in-one! I'm trying to create osgi component exactly like the ImageTool component in Liferay 7. I've implemented my ImageDisplayUtil and ImageDisplay Please sign in to reply. Reply as... Cancel
Petr Jung 5 Years Ago Hi David H, We need to upgrade our portlets from LR6.2 to LR7.1. This portlets use massively Spring 4.3.22. I understand, that between modules I should use the DS, but internally I want to stay in Spring. The aim is when activated, the module start spring context as in the past and register additionally the DS services. I did a couple of test and it seems the Liferay OSGi Spring extender inject on the classpath the Spring 4.1.9 version and there is no way to configure the budle to overload it, even if you pack directly into a each bundle. I need to upgrade the Spring to 4.3.19, or even better 5.x. Is there a option to write own extender, which will be applied just for osgi bundles with some Require-Capability´s and the Liferay extender will be skipped there? Thanks for reply, or whom I can as for? Petr Please sign in to reply. Reply as... Cancel