Am 17.10.14 um 12:26 schrieb Stefan Seifert: > >> 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? > > > proposal how the API can be used: > > --- > Configuration config = resource.adaptTo(Configuration.class); > > // single access > String value = config.get(MyTypedConfig.class).getParam1(); > > // multiple acces > MyTypedConfig[] myconfigs = config.getMultiple(MyTypedConfig.class); > String value = myconfigs[0].getParam1() > --- > > i thought about if we can get rid of the Configuration.class at all and > directly use MyTypedConfig.class or MyTypedConfig[].class in the adaptTo() > call, but i'm not sure if that’s working with annotation types. or use > Configuration.class only in cases where you need string-based value map > access. > > i currently do not see a need for a "key" when accessing the typed > configuration. >
Right, the resource path is the key - I'm fine with that. I guess we need the Configuration for all use case where people don't want to define their configuration type. Directly adapting to MyTypedConfig or MyTypedConfig[] class is nice, but requires that you register each and every configuration type through an adapter factory. And if you want to use a different one, this gets difficult. So I think adding an adaptTo method to Configuration might do the trick: MyTypedConfig = resource.adaptTo(Configuration.class).adaptTo(MyTypedConfig.class); The adaption within the implementation of the configuration class can be done on the fly by creating a proxy. We should check if esource.adaptTo(Configuration.class).adaptTo(MyTypedConfig[].class) would be implementable as well. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
