Hi Alain, > 1) How to deal with references in classes that are not service and that have > constructor arguments (and not basic type supported by config admin) since > this can't be turned directly into a component?
It depends on the constructor really. You can either have a DS component which just instantiates the class and delegates to it, or publishes it. If the constructor is amenable then you could also consider using constructor injection <https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-constructor.injection> to turn the type directly into a component. Note that this isn’t yet supported by bnd tooling <https://github.com/bndtools/bnd/issues/2179> (PRs are welcome!) but is targeted for 4.1 > 2) How to deal with abstract classes that serve as the foundation for a > number of other service/component classes and their required references? > should those be abstracted in those abstract classes? Inheritance of Declarative Services annotations is usually a bad thing. The resulting XML file generated from the annotations ends up tightly coupled to private internals all the way up the class hierarchy, if the abstract class changes in a binary compatible way then this can still break the DS component. All of the references should be injected into the concrete component type and passed up to the abstract class. This could also be done using Constructor injection. > 3) How to deal with class specialization of a service class. Is that a > problem? I’m not sure what you mean here. The service should advertise its service interface and that’s what people should use to talk to it… Best Regards, Tim > On 28 Jun 2018, at 17:47, Alain Picard via osgi-dev <osgi-dev@mail.osgi.org> > wrote: > > We have a pretty large codebase from an Eclipse PDE RCP EMF application which > we are moving to a web/servlet type application. As part of this effort we > are fully moving to run in an OSGI framework and leveraging as much as > possible native OSGI approaches like DS. Many of our struggles are surely > related to refactoring and using existing libraries, since we can't fully > redesigned everything from scratch. > > As we start to transform part of the codebase to DS, we are faced with the > following cases for which we need to understand best practices. For now we > have applied some more traditional approach with service tracker and service > reference, but that doesn't feel like the best way to go about it. > > 1) How to deal with references in classes that are not service and that have > constructor arguments (and not basic type supported by config admin) since > this can't be turned directly into a component? > > 2) How to deal with abstract classes that serve as the foundation for a > number of other service/component classes and their required references? > should those be abstracted in those abstract classes? > > 3) How to deal with class specialization of a service class. Is that a > problem? > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
