Am 15.10.14 um 09:01 schrieb Stefan Seifert: > 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. Right, but given that you already see hundreds of annotations there...
> > 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. Sure, the spec can be found here https://github.com/osgi/design/blob/master/rfcs/rfc0190/rfc-0190-Declarative_Services_Enhancements.pdf > > 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. Yeah, sure - but I kind of like the more compact notation of an annotation compared to having to annotate each field in the interface. And an interface can define arbitrary methods, with arguments, complex objects as return types etc. On the other hand annotations provide exactly what you need for a configuration, the basic types and arrays of those (ok, there is also Class allowed as a type). I would be fine with going with interfaces as well - as long as we have typed configurations objects which are a) easy to describe and b) easy to use. > > 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]. Ok. Regards Carsten > > 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 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
