felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com.INVALID>
Subject Re: [DS] Possible extensions to RFC 190 configuration-through-annotation support
Date Tue, 05 Aug 2014 06:06:16 GMT
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).

david jencks

On Aug 4, 2014, at 10:47 PM, Carsten Ziegeler <cziegeler@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 <david_jencks@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message