I would like to implement the following extensions to the RFC 190
configuration-through-annotation support. I think they are generally useful so
I would like to discuss implementing them directly in felix DS. If there's
significant opposition and I still think this is a good idea :-) I could also
implement some kind of plugin-to-DS mechanism so I can replace the default
annotation configuration processing.
1. Interfaces instead of annotations. One of the unfortunate limitations of
annotations is that they are final, whereas it may be useful to have a type
hierarchy in your configuration classes. It would also be possible to support
a slightly wider choice of element types, such as wrapper classes (Integer etc)
and possibly List or Set or Collection instead of Array (I'm not so sure about
this last one). I believe the main reason for limiting the spec to annotations
is that it provides an all-in-one way to specify default configuration.
However, if you are using metatype you can also specify them with metatype
annotations.
2. Nested configuration/annotations. This means (for annotations) supporting
annotation elements that are annotations or arrays of annotations. This is
obviously extremely useful for complicated configuration, but requires some way
of encoding the tree structure of the configuration into the flat properties
map.
Flat tree encodings. I know of two strategies: encoding each branch off the
root into a top level element (whose value will then have an arbitrarily
complex structure) or encoding each leaf of the tree into a top level element.
I prefer the second approach. Among the advantages is that the values are al
subject to the existing configuration type constraints. In order to do this
you have to generate a key that uniquely identifies the leaf. I've used a
method similar to xml query syntax, adapted to the key token restrictions (I
actually cribbed this from James Strachan's Spring DSL for ActiveMQ
configuration). Here's a simple example, starting with an xml representation
of a configuration tree:
<configuration name="config">
<foo fooName="foo1">
<bar attr="a"/>
<bar attr="b"/>
</foo>
<foo fooName="foo2">
<bar attr="c"/>
</foo>
</configuration>
is converted to a map like:
name=config
foo.0.fooName=foo1
foo.0.bar.0.attr=a
foo.0.bar.1.attr=b
foo.1.fooName=foo2
foo.1.bar.0.attr=c
At this point I don't want to complicate the issue by discussing specifying
such configurations using metatype (with extensions). It is possible to do.
This is a somewhat condensed description, so if anything isn't clear please ask
for an explanation.
Thoughts?
thanks
david jencks
