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

Reply via email to