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 >> <mailto: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 <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 <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
