Hi, produces property-placeholder looks of course like this: <property-placeholder xmlns="http://aries.apache.org /blueprint/xmlns/blueprint-cm/v1.1.0" persistent-id="org.apache.aries.my" placeholder-prefix="$[" placeholder-suffix="]" update-strategy="reload"> <default-properties> <property name="title" value="My Title"/> </default-properties> </property-placeholder>
I also suggest changing org.apache.aries.blueprint.api.config.Property to org.apache.aries.blueprint.api.config.DefaultProperty because there is already annotation @Property in org.ops4j.pax.cdi.api and is used during service exposing. 2016-10-18 11:40 GMT+02:00 Christian Schneider <ch...@die-schneider.net>: > After discussing some more with Dominik I came up with this design: > > https://github.com/apache/aries/blob/trunk/blueprint/bluepri > nt-maven-plugin/src/test/java/org/apache/aries/blueprint/ > plugin/test/BeanWithConfig.java > > 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="http://aries.apache.org > /blueprint/xmlns/blueprint-cm/v1.1.0" persistent-id="org.apache.aries.my" > placeholder-prefix="reload" placeholder-suffix="reload" > update-strategy="reload"> > <default-properties> > <property name="title" value="My Title"/> > </default-properties> > </property-placeholder> > > <bean id="beanWithConfig" class="org.apache.aries.bluepr > int.plugin.test.BeanWithConfig" ext:field-injection="true"> > <property name="title" value="$[title]"/> > </bean> > > 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. > > Christian > > 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. >> >> >> 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 > > -- Pozdrawiam / Regards, Dominik Przybysz
