You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by David Jencks <da...@yahoo.com.INVALID> on 2014/08/05 02:34:29 UTC
[DS] Possible extensions to RFC 190 configuration-through-annotation support
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
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
Re: [DS] Possible extensions to RFC 190 configuration-through-annotation
support
Posted by Carsten Ziegeler <cz...@apache.org>.
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