I also suggest changing of package to org.apache.aries.blueprint. *annotation*.config
2016-10-18 13:46 GMT+02:00 Dominik Przybysz <alien11...@gmail.com>: > 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/plu >> gin/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 > -- Pozdrawiam / Regards, Dominik Przybysz
