> 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. > 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. > 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. > Sometimes it would be nice to find the annotated methods/fields at runtime, > e.g. at testing in a non-OSGi environment > 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. > 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? > > 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 https://mail.osgi.org/mailman/listinfo/osgi-dev
