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

Reply via email to