You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Carsten Ziegeler <cz...@apache.org> on 2014/08/05 07:47:38 UTC
Re: [DS] Possible extensions to RFC 190 configuration-through-annotation
support
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 <da...@yahoo.com.invalid>:
> 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
cziegeler@apache.org
Re: [DS] Possible extensions to RFC 190 configuration-through-annotation support
Posted by David Jencks <da...@yahoo.com.INVALID>.
Yes, I completely agree that you should have to explicitly enable this behavior, I forgot to mention that :-)
I implemented parsing of per-component flags in the xml descriptor (in a felix namespace), was thinking this one might be
public static final String CONFIGURE_WITH_INTERFACES = "configureWithInterfaces";
(there are a bunch of these in XmlHandler, comments on better names appreciated).
(I have a generic and somewhat inconvenient way for bnd to add these flags from annotations, I need to talk to Peter about a pluggable less-generic more-convenient solution).
thanks
david jencks
On Aug 4, 2014, at 10:47 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> 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 <da...@yahoo.com.invalid>:
>
>> 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
> cziegeler@apache.org