Hi Carsten, I have two concerns with this model: 1) Creating an annotation class can be a bit heavyweight. If I want to just store a common value used across multiple scripts, doing so would require creating this class, compiling it, deploying the bundle, etc. vs. just adding a node property and referencing the property name from my scripts (the constant is a nice-to-have, but not strictly necessary). This is a non-issue for DS because the configuration annotation is tightly coupled with the configured component. But to my mind, one of the key targets for this new configuration structure is scripts. 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'm also a bit concerned about the use of annotations in this way because they can't be extended (at least I think this is true). I'm not sure if this is a solved issue for DS configurations. I'll have to read more of the spec to see how/if this problem is being solved there. Regards, Justin On Wed, Oct 15, 2014 at 2:24 AM, Carsten Ziegeler <cziege...@apache.org> wrote: > 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