I’m afraid I don’t understand what the problems you see are, perhaps because I
use blueprint so infrequently. Could you provide little code snippets to
illustrate?

Advertising

Recall that in the DS approach many components in the same bundle can use the
same pid, and that a config annotation used by a DS component doesn’t have to
use all of the expected configuration properties. Whatever information happens
to be in the configuration is stuffed into the annotation however it will fit.
So each component can have an annotation with only the properties it actually
is interested in.
thanks
david jencks
> On Oct 11, 2016, at 10:50 PM, Christian Schneider <ch...@die-schneider.net>
> wrote:
>
> I like the approach in DS to supply the config in one event but I don´t
> think it matches how dependency injection in blueprint works.
>
> In blueprint that config is often applied in different beans. Each bean is
> injected with config and its dependencies. Only after this step the
> init-method is used and the bean is injected into other beans. If I would
> get the config in a single event then it would be too late to inject it
> into other beans.
>
> So the only way I could imagine this to work is to inject the full config
> into each bean that needs it. This could be done a parameter of the init
> method (which is then similar to DS).
> The problem is that then several beans are tied together by the config even
> if they just need one attribute of it. Another problem is that by applying
> the config in each bean separately (and I think this is the only safe
> approach in blueprint) we loose the advantage of the single event.
>
> So while I am sure we can technically do it like in DS I think it would
> work less well from a design point of view.
>
> Christian
>
> 2016-10-11 17:12 GMT+02:00 David Jencks <david_jen...@yahoo.com.invalid>:
>
>> I don’t think i would consider ever recommending anyone use blueprint for
>> anything, but if I were to design something like this I would take the
>> opportunity to get one of the big advantages of DS also in blueprint, that
>> all the configuration info is supplied in one event. So using your
>> annotation example (which would not need the @ObjectClassDefinition for
>> this use)
>>
>> @Inject @Named(<pid>)
>> private ServerConfig serverConfig;
>>
>> When a configuration with the appropriate pid shows up, a ServerConfig
>> implementation returning the values from the configuration is created and
>> injected. If the configuration is a factory configuration with the pid as
>> the factory pid, then for each such configuration an instance is created.
>>
>> This doesn’t have the flexibility of what DS does (multiple pids, no
>> necessary direct connection between pid and configuration annotation) but
>> something with those properties wouldn’t be hard to design.
>>
>> Metatype is extremely useful and generating metatype from annotations is
>> incredibly nice, but I would try to avoid requiring metatype for every
>> configuration annotation.
>>
>> david jencks
>>
>>> On Oct 11, 2016, at 2:57 AM, Christian Schneider <
>> ch...@die-schneider.net> wrote:
>>>
>>> By default @Named("key") is used to inject a certain bean when type
>> information alone is not unique. In blueprint-maven-plugin we map it to a
>> bean id.
>>> So simply using the key for configs might overlap too easy. So I am not
>> sure which exact syntax we should use but the simple name is not enough.
>>>
>>> Support of different placeholders is also something that would be great
>> to support. It is rather rare but people use it.
>>> I think the must have is that we support placeholders from one config
>> and the system properties or framework properties.
>>>
>>> Christian
>>>
>>> On 11.10.2016 11:22, Guillaume Nodet wrote:
>>>> I like the use of annotations for config.
>>>> I've implemented it for CDI and it's quite nice.
>>>> I'm not sure that reusing @ObjectClassDefinition is a good idea, afaik
>> SCR
>>>> does not use it either.
>>>> I'd rather create a new blueprint annotation for such support.
>>>>
>>>> Also, I'm a bit skeptic about @Named("${key}") and
>> @Named("$system{key}")
>>>> Why not using something simpler: @Named("key") and @Named("system:key")
>> ?
>>>> Or is that to support multiple placeholders with different syntaxes
>> (${xx},
>>>> $[yy]...) ?
>>>>
>>>>
>>>>
>>>> 2016-10-11 10:15 GMT+02:00 Christian Schneider <ch...@die-schneider.net
>>> :
>>>>
>>>>> Currently config is done in the blueprint-maven-plugin in this way:
>>>>>
>>>>> - Define a property-placeholder element in xml (using the cm
>> namespace).
>>>>> This defines the reference to the pid and optionally the default
>> values.
>>>>>
>>>>> - Use @Value("${key}") in the java code to inject a config value into a
>>>>> field.
>>>>>
>>>>>
>>>>> Problems
>>>>>
>>>>> * The approach above requires a mix of xml and annotations.
>>>>> * @Value is a spring annotation. So the user code needs to refer to
>>>>> the spring library (even if it is not needed at runtime)
>>>>>
>>>>>
>>>>> Goals
>>>>>
>>>>> * Pure annotation approach
>>>>> * Should only need API dependencies in user code. Ideally these should
>>>>> not bring unwanted additional annotations that we can not use.
>>>>>
>>>>>
>>>>> Idea
>>>>>
>>>>> The OSGi meta type spec allows to define type safe config using
>>>>> annotations. We could use the same constructs to define blueprint
>> configs.
>>>>>
>>>>> It looks like this:
>>>>>
>>>>> |@ObjectClassDefinition(pid="my.config.id") @interface ServerConfig {
>>>>> String host() default "0.0.0.0"; int port() default 8080; boolean
>>>>> enableSSL() default false; }|
>>>>>
>>>>> This could be done in a new blueprint config namespace that enables the
>>>>> annotation processing. In this case the blueprint-maven-plugin just
>> needs
>>>>> to add the namespace and enable element to the generated blueprint.
>>>>>
>>>>> Another approach is to parse the config in the blueprint-maven-plugin
>> and
>>>>> create a property placeholder Element in our current style.
>>>>>
>>>>> If we have the above then we still need an annotation based way to
>> inject
>>>>> the config. One possible solution would be to use @Named with a special
>>>>> syntax:
>>>>>
>>>>> @Inject @Named("${key}")
>>>>> String myAttribute;
>>>>>
>>>>> We could also cover system properties in this way:
>>>>>
>>>>> @Inject @Named("$system{key}")
>>>>>
>>>>> This approach has the advantage that it does not require any new
>>>>> annotation but it bends the purpose of the @Named annotation a bit.
>>>>>
>>>>> WDYT?
>>>>>
>>>>>
>>>>> Christian
>>>>>
>>>>> --
>>>>> Christian Schneider
>>>>> http://www.liquid-reality.de
>>>>>
>>>>> Open Source Architect
>>>>> http://www.talend.com
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de <http://www.liquid-reality.de/>
>>>
>>> Open Source Architect
>>> http://www.talend.com <http://www.talend.com/>
>>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>