After discussing some more with Dominik I came up with this design:

The main annotations are @Config to configure the property-placeholder Element and @ConfigProperty to inject a value. The Config annotation must be placed on any blueprint bean but will add config for the whole blueprint context of course.

We did not use the meta type annotations to not mix the aspects. This is currently coverying the blueprint approach of injecting config into individual properties. For the type safe approach we should wait until blueprint supports this and then add suitable support in the maven plugin.

This is the code the above bean produces.

<property-placeholder xmlns=""; persistent-id="" placeholder-prefix="reload" placeholder-suffix="reload" update-strategy="reload">
<property name="title" value="My Title"/>

<bean id="beanWithConfig" class="org.apache.aries.blueprint.plugin.test.BeanWithConfig" ext:field-injection="true">
    <property name="title" value="$[title]"/>

What do you think about this approach? Until the next release we are still free to change this.
For example I wonder if @ConfigProperty maybe should be called @ConfigValue.


On 11.10.2016 10:15, Christian Schneider wrote:

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.


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


  * Pure annotation approach
  * Should only need API dependencies in user code. Ideally these
    should not bring unwanted additional annotations that we can not use.


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="") @interface ServerConfig { String host() default ""; 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.



Christian Schneider

Open Source Architect

Christian Schneider

Open Source Architect

Reply via email to