Do these properties “represent” classes or are they actually classes? If they are just representations (which would be a good thing) then you can define a static string constant representing the class which is mapped internally to the correct class name (which can then change over time). Clients then filter based on the string representation which will not change.
Tim > On 24 Aug 2018, at 10:07, Alain Picard <pic...@castortech.com> wrote: > > Tim & all, > > My immediate use case is that my components have some properties and some of > those represent classes (this interfaces with 3rd party libraries, I would > probably design it differently if I could, but it has to be configuration as > it is used to determine if the component is a match, much like for target > filters). Properties in the component annotation are String[] and that forces > the specification of classes as String which is very bad since if the class > is moved, renamed, deleted, etc, it will cause no error or warning and blow > up later on. And since annotations only support compile time constants, you > can't do a MyClass.class.getName() to even get a String. My idea was since > the implementation class is part of the component description, if I could get > a hold of it, to have a static method in the class to provide this "constant". > > How can I work around the limitations of Properties as String and Java > compile time constants. Am I stuck to introduce a new separate annotation to > track this configuration? > > Alain > > Alain > > > On Thu, Aug 23, 2018 at 5:24 AM Tim Ward <tim.w...@paremus.com > <mailto:tim.w...@paremus.com>> wrote: > The properties visible in the Map (or ServiceReference) are the service > properties. There is some overlap with configuration (services that are > configurable are encouraged to publish configuration properties as service > properties) but they are separate, and can be different. > > The only way that something becomes a service property is if it is > deliberately registered as such or, for a few specific properties such as > service.id <http://service.id/> and service.scope, added automatically by the > framework. > > The class name of the implementation would only be added as a service > property if done so deliberately, and this is typically discouraged (it leaks > internal implementation detail and forces your internal naming to become > API). If you *really* care about the details of a service (and in general you > shouldn’t) then you should mark it with a service property that you can > recognise. Ideally one that is separate from the other implementation details > of the service. > > Best Regards, > > Tim > > > On 22 Aug 2018, at 16:53, Alain Picard via osgi-dev <osgi-dev@mail.osgi.org > > <mailto:osgi-dev@mail.osgi.org>> wrote: > > > > In a reference method, i can get the property configuration of the service > > along with the ComponentFactory and some other optional arguments. Can any > > of those give me a way to retrieve the implementation from the > > configuration (i.e. the class name of the implementation) ? > > > > Thanks > > Alain > > > > _______________________________________________ > > 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
