Am 15.10.14 um 15:40 schrieb Justin Edelson:
> 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.
The use cases I know and have heard of are not script related, the
configurations are evaluated on java code, so I have a bundle already
and creating the annotation then is easy. But I see your point and I see
no reason why we shouldn't support the direct access of properties but
recommend to use properly typed objects.
> 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 haven't thought of this part yet, I've just stated my strong wish
for strongly typed configuration objects :)
> 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.
>
In DS its simple, there is no extension - annotations don't support
inheritance. But you can use as many annotations, so instead of doing
annotation B extends annotation A and then use B, you use A and B.
Carsten
> 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
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
