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


-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Reply via email to