Thanks a lot for this quick, in-depth answers :) 2017-09-28 10:01 GMT+02:00 Thomas Driessen <thomas.driessen...@gmail.com>:
> > ---------- Forwarded message ---------- > From: Timothy Ward <tim.w...@paremus.com> > Date: 2017-09-27 16:05 GMT+02:00 > Subject: Re: [osgi-dev] Some questions > To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > Cc: Thomas Driessen <thomas.driessen...@gmail.com> > > > Some more responses inline: > > On 27 Sep 2017, at 14:29, Neil Bartlett <njbartl...@gmail.com> wrote: > > > On 27 Sep 2017, at 14:14, Thomas Driessen <thomas.driessen...@gmail.com> > wrote: > > Hi, > > after working for some time with OSGi now I have a bunch of questions that > I couldn't find a satisfying answer for yet. Maybe some of you can help me > to clarify those: > > 1) Why is OSGi using annotations as configuration objects? > > > Two reasons: > 1. Annotation fields can have defaults specified directly. > 2. Annotation types are limited to primitives, Strings (and arrays > thereof) which map neatly to the kinds of data that can be represented in > config files. > > > - It is really strange that within an @Activate method the > annotation-config object is null but I still can call the methods defined > on it. > > The default toString of the Felix SCR configuration proxies used to be > null. This proved very confusing in the debugger, and I believe that it has > been changed in recent releases. > > > - Wouldn't DTOs be the better choice? Maybe in combination with an > annotation and annotation processor that assures the DTO consists only of > primitives, arrays of primitives or other DTOs. Configuration values like “ > component.name" could be represented as values of a ConfigurationDTO > containing a ComponentDTO which has a name variable. > > DTOs don’t give a good way of providing defaults, and they encourage > people to believe that the configurations can contain rich types (you > mention your DTO containing DTOs). Configuration Admin configurations are > flat, and Annotations give a really good mapping for them. The decision was > therefore to use the type which is well suited, rather than building a lot > of infrastructure to restrict a type which isn’t. > > 2) Why are the OSGi DS annotations RetentionPolicy.CLASS? > > > > Because runtime retention would create a runtime dependency, i.e. an > Import-Package for the annotation type package. That in turn would prevent > resolution of a bundle if the annotations were not present at runtime. > > > Also the annotations are not used by the Service Component Runtime, only > the XML is used. Having runtime retention would confuse what is otherwise a > clear statement about the source of truth. > > > > - Sometimes it would be nice to find the annotated methods/fields at > runtime, e.g. at testing in a non-OSGi environment > > You could just read the XML descriptor - it has a well defined schema. > > 3) Why are the OSGi DS annotations not inherited? > > > > You might be using bnd (or an alternative tool) to process the class files > of a bundle after the Java source has been compiled. When doing this it is > not necessary to have the superclasses visible, and so bnd would not know > about inherited annotations. So if bnd looks for inherited annotations when > available, it could produce different results depending on how it is > invoked. > > In practice, most people use a tool like Bndtools or bnd-maven-plugin > which puts the same JARs on the bnd classpath that were used for > compilation, and you obviously DO need superclasses visible for > compilation, so you can just turn on the option to use inheritance. > > > - I know that there is a option in bnd for this, but I’m not sure if > or when it is save to use this option, as I'm not really sure about the > implications this might have. > > This option is safe if all of the class hierarchy is contained within a > single bundle. It is not safe if the inheritance tree spans different > bundles. The annotations are processed at build time based on the > compilation class path but the runtime behaviour is determined by the way > in which your bundles wire in the OSGi framework. Obviously if your bundle > wires differently at runtime then the generated XML may be broken (for > example if an injected private field is renamed between micro versions). > > > - Are there any best practices/patterns for the cases where I have > mutliple implementations of one service and all of them share code that > should be called e.g. during activation or deactivation? > > Good unit tests are usually enough, but JavaDoc and an abstract method > which forces the subclasses to implement an activate/deactivate method can > help. > > > Any explanation is appreciated :) > > Kind regards, > Thomas > _______________________________________________ > 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 > > > >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
