> On 29 Jun 2018, at 14:57, Alain Picard <pic...@castortech.com> wrote: > > > Thanks Tim, see below. > > On Fri, Jun 29, 2018 at 8:12 AM Tim Ward <tim.w...@paremus.com > <mailto:tim.w...@paremus.com>> wrote: > 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 > > I have been reading this section about constructor injection and didn't > realize that it is new in R7. The key term here is "amenable" since there are > clear restrictions on what can be injected. I have successfully tried a > strategy of scope prototype with @Reference prototype required to guarantee > getting a specific instance since I have "constructor level state" and I am > using an init method to replace the previous constructor. Do you see that as > a valid approach. Your idea of more of a wrapper makes a lot of sense > especially when dealing with existing libraries that we can't really change.
That sounds like a reasonable approach. It’s perfectly acceptable for a DS component to use the new operator to create a bunch of types and manage/delegate to them. Init methods are pretty similar to the existing DS activate methods, and so should also fit relatively well from a lifecycle perspective. > >> 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. > > Will see what we can do here. Ouch! We have a lot of complex class > hierarchies instead of service composition. This sounds like it will be something that you unpick over time. Inheritance isn’t a bad thing, but it can be a problem if the chains get long. > >> 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… > > Well again deep class hierarchies where some "service" components extend > another component to either specialize the service or provide additional > inherited functionalities. The services should advertise every API type that someone should be able to use them as (including super types). This way when someone looks for an instance in the service registry then they will find it. If you fail to advertise the super types then the service registry will not return your service when someone looks for a super type of what it has advertised. For example, if I am looking for a service of type Collection then I will not see one that is advertised as a List, even though a List can be transparently widened to a Collection. You should therefore advertise as a List *and* a Collection. Note that this does not mean that you should advertise that you are a LinkedList because that is not part of your API! Best Regards, Tim > > > Best Regards, > > Tim > > >> On 28 Jun 2018, at 17:47, Alain Picard via osgi-dev <osgi-dev@mail.osgi.org >> <mailto: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 <mailto:osgi-dev@mail.osgi.org> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> <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
