Am 17.10.14 um 12:02 schrieb Stefan Seifert: > >>> 2) I'm assuming that the lookup key for these configuration objects is >>> the class name. IMHO, we need some kind of differentiator, see for >>> example my OAuth example earlier in this thread. >>> >> I haven't thought of this part yet, I've just stated my strong wish >> for strongly typed configuration objects :) > > it seems as we would need some sort of factory-configuration for this usecase > as well? this would be problematic in my initial approach with only a flat > list of properties in a valuemap as well. > > an oauth bundle would provide an annotation type class and mark it as > "multiple" or "factory". the API has to provide a way to get lists of > annotation class instances to iterate over. the configuration editor has to > support it as well. should be possible, although it would make the API a bit > more complex. >
I'm just thinking out loud, especially as I don't have that much experience in this area. But what is the preferred way to get a configuration? I would assume that you get a configuration for a key similar to the pid for OSGi configurations. From an API point of view a T[] getConfiguration(String key, Class<T> type); for a single and T[] getConfigurations(String key, Class<T> type); for multiple would do? Again, just talking out loud without thinking of anything else related to this stuff. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
