hello carsten. like it! so each application defines one (or multiple) of such configuration annotation classes. the first get on an configuration object would expect an annotation class, and the second would be nice typed access to a configuration value. providing additional metadata per configuration parameter (e.g. for a configuration editor) would still be possible by adding annotations to the annotation methods.
of course we somewhat misuse the annotation concept here because it's never used as annotation at all - but it works quite well and is very comfortable. the only drawback i see that such annotations will be presented as well to users in their IDEs when typing @... to see what annotations are available to annotate their classes. do you have a link where such a concept is defined in context of the new DS specification? using the same concept as a (new) DS version would be plus. wouldn't it be an option to use a plain interface with default values as annotations? this comes close to what sling models supports today. my statement about "support only types from JCR" was not precise - i meant support all primitive types including string array plus map, but no custom or more advanced objects, because this would make things really complicated. currently a subset of primitive types is supported [1]. stefan [1] http://wcm.io/config/api/usage-spi.html#Providing_parameter_definitions >-----Original Message----- >From: Carsten Ziegeler [mailto:cziege...@apache.org] >Sent: Wednesday, October 15, 2014 8:24 AM >To: dev@sling.apache.org >Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, >Multitenancy > >In general, using typed objects is the preferred way to go, so I think a >configuration object should be a type object and return configuration >values in the correct type. Let's not fall back into the 80s and fiddle >around with string conversions all over the place. >Having a type for a configuration removes also the need for those ugly >name constants and we could hopefully also get away with having ugly >constants for default values. > >So what about using the approach we use in the new Declarative Service >specification and you define a configuration as an annotation: > >public @interface MyConfiguration { > > int port() default 465; > > String host() default "localhost"; > > String userId; >} > >This leaves us with a single place to define a type configuration object >in combination with default values. We then define simple mapping rules >from names to resource names. > >And we should also support *all* java types not just those JCR supports. >Internally all numbers can be stored as long but the configuration >object gives you an integer, char whatever. > >This is how I would like to deal with configurations in code. > >Carsten > >-- >Carsten Ziegeler >Adobe Research Switzerland >cziege...@apache.org
