Thanks for the feedback Tim
On Fri, Jun 29, 2018 at 10:40 AM Tim Ward <tim.w...@paremus.com> wrote: > > > 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> 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> 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
