Hi David, in general I like the idea - as you note, RFC 190 sticks to annotations because of type safety when it comes to specifying the default value - and to keep it simple :) While I agree with the limitations of annotations (no inheritance etc.) I'm not sure if you really need this - maybe yes. So I think it makes sense to add this to our implementation to find out how it really works in practice - and people have asked for complex config structures for years. Let's give it a try. Could we add a global switch to enable/disable this - so if people want to be 100% compliant with the spec, they can simply turn this off? I don't have a better idea for the nested configurations/xml mapping, but looks fine for me as well
Regards Carsten 2014-08-05 2:34 GMT+02:00 David Jencks <[email protected]>: > 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 > > > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
