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
