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
Open Source Architect
http://www.talend.com
