> On 27. Sep 2017, at 16:05, Timothy Ward <tim.w...@paremus.com> wrote: > > 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.
This has indeed been fixed now (tracked in https://issues.apache.org/jira/browse/FELIX-5543). > >>> • 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 Konrad _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
