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/>
