You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Christian Schneider <ch...@die-schneider.net> on 2016/10/11 08:15:28 UTC
[blueprint-maven-plugin] Ideas for config handling
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
Re: [blueprint-maven-plugin] Ideas for config handling
Posted by Dominik Przybysz <al...@gmail.com>.
I also suggest changing of package to org.apache.aries.blueprint.
*annotation*.config
2016-10-18 13:46 GMT+02:00 Dominik Przybysz <al...@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
Re: [blueprint-maven-plugin] Ideas for config handling
Posted by Dominik Przybysz <al...@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/
> 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
Re: [blueprint-maven-plugin] Ideas for config handling
Posted by 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/blueprint-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.blueprint.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
Re: [blueprint-maven-plugin] Ideas for config handling
Posted by Christian Schneider <ch...@die-schneider.net>.
If you can share the config between components by using it in different
places then it can indeed work in the same way with blueprint.
I always though the idea in DS would be to only inject the config at one
place. (Lots to learn still :-)
Christian
On 12.10.2016 09:29, David Jencks wrote:
> I\u2019m afraid I don\u2019t understand what the problems you see are, perhaps because I use blueprint so infrequently. Could you provide little code snippets to illustrate?
>
> Recall that in the DS approach many components in the same bundle can use the same pid, and that a config annotation used by a DS component doesn\u2019t have to use all of the expected configuration properties. Whatever information happens to be in the configuration is stuffed into the annotation however it will fit. So each component can have an annotation with only the properties it actually is interested in.
>
> thanks
> david jencks
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [blueprint-maven-plugin] Ideas for config handling
Posted by David Jencks <da...@yahoo.com.INVALID>.
I’m afraid I don’t understand what the problems you see are, perhaps because I use blueprint so infrequently. Could you provide little code snippets to illustrate?
Recall that in the DS approach many components in the same bundle can use the same pid, and that a config annotation used by a DS component doesn’t have to use all of the expected configuration properties. Whatever information happens to be in the configuration is stuffed into the annotation however it will fit. So each component can have an annotation with only the properties it actually is interested in.
thanks
david jencks
> On Oct 11, 2016, at 10:50 PM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> I like the approach in DS to supply the config in one event but I don´t
> think it matches how dependency injection in blueprint works.
>
> In blueprint that config is often applied in different beans. Each bean is
> injected with config and its dependencies. Only after this step the
> init-method is used and the bean is injected into other beans. If I would
> get the config in a single event then it would be too late to inject it
> into other beans.
>
> So the only way I could imagine this to work is to inject the full config
> into each bean that needs it. This could be done a parameter of the init
> method (which is then similar to DS).
> The problem is that then several beans are tied together by the config even
> if they just need one attribute of it. Another problem is that by applying
> the config in each bean separately (and I think this is the only safe
> approach in blueprint) we loose the advantage of the single event.
>
> So while I am sure we can technically do it like in DS I think it would
> work less well from a design point of view.
>
> Christian
>
> 2016-10-11 17:12 GMT+02:00 David Jencks <da...@yahoo.com.invalid>:
>
>> I don’t think i would consider ever recommending anyone use blueprint for
>> anything, but if I were to design something like this I would take the
>> opportunity to get one of the big advantages of DS also in blueprint, that
>> all the configuration info is supplied in one event. So using your
>> annotation example (which would not need the @ObjectClassDefinition for
>> this use)
>>
>> @Inject @Named(<pid>)
>> private ServerConfig serverConfig;
>>
>> When a configuration with the appropriate pid shows up, a ServerConfig
>> implementation returning the values from the configuration is created and
>> injected. If the configuration is a factory configuration with the pid as
>> the factory pid, then for each such configuration an instance is created.
>>
>> This doesn’t have the flexibility of what DS does (multiple pids, no
>> necessary direct connection between pid and configuration annotation) but
>> something with those properties wouldn’t be hard to design.
>>
>> Metatype is extremely useful and generating metatype from annotations is
>> incredibly nice, but I would try to avoid requiring metatype for every
>> configuration annotation.
>>
>> david jencks
>>
>>> On Oct 11, 2016, at 2:57 AM, Christian Schneider <
>> chris@die-schneider.net> wrote:
>>>
>>> By default @Named("key") is used to inject a certain bean when type
>> information alone is not unique. In blueprint-maven-plugin we map it to a
>> bean id.
>>> So simply using the key for configs might overlap too easy. So I am not
>> sure which exact syntax we should use but the simple name is not enough.
>>>
>>> Support of different placeholders is also something that would be great
>> to support. It is rather rare but people use it.
>>> I think the must have is that we support placeholders from one config
>> and the system properties or framework properties.
>>>
>>> Christian
>>>
>>> On 11.10.2016 11:22, Guillaume Nodet wrote:
>>>> I like the use of annotations for config.
>>>> I've implemented it for CDI and it's quite nice.
>>>> I'm not sure that reusing @ObjectClassDefinition is a good idea, afaik
>> SCR
>>>> does not use it either.
>>>> I'd rather create a new blueprint annotation for such support.
>>>>
>>>> Also, I'm a bit skeptic about @Named("${key}") and
>> @Named("$system{key}")
>>>> Why not using something simpler: @Named("key") and @Named("system:key")
>> ?
>>>> Or is that to support multiple placeholders with different syntaxes
>> (${xx},
>>>> $[yy]...) ?
>>>>
>>>>
>>>>
>>>> 2016-10-11 10:15 GMT+02:00 Christian Schneider <chris@die-schneider.net
>>> :
>>>>
>>>>> 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 <http://www.liquid-reality.de/>
>>>
>>> Open Source Architect
>>> http://www.talend.com <http://www.talend.com/>
>>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: [blueprint-maven-plugin] Ideas for config handling
Posted by Christian Schneider <ch...@die-schneider.net>.
I like the approach in DS to supply the config in one event but I don´t
think it matches how dependency injection in blueprint works.
In blueprint that config is often applied in different beans. Each bean is
injected with config and its dependencies. Only after this step the
init-method is used and the bean is injected into other beans. If I would
get the config in a single event then it would be too late to inject it
into other beans.
So the only way I could imagine this to work is to inject the full config
into each bean that needs it. This could be done a parameter of the init
method (which is then similar to DS).
The problem is that then several beans are tied together by the config even
if they just need one attribute of it. Another problem is that by applying
the config in each bean separately (and I think this is the only safe
approach in blueprint) we loose the advantage of the single event.
So while I am sure we can technically do it like in DS I think it would
work less well from a design point of view.
Christian
2016-10-11 17:12 GMT+02:00 David Jencks <da...@yahoo.com.invalid>:
> I don’t think i would consider ever recommending anyone use blueprint for
> anything, but if I were to design something like this I would take the
> opportunity to get one of the big advantages of DS also in blueprint, that
> all the configuration info is supplied in one event. So using your
> annotation example (which would not need the @ObjectClassDefinition for
> this use)
>
> @Inject @Named(<pid>)
> private ServerConfig serverConfig;
>
> When a configuration with the appropriate pid shows up, a ServerConfig
> implementation returning the values from the configuration is created and
> injected. If the configuration is a factory configuration with the pid as
> the factory pid, then for each such configuration an instance is created.
>
> This doesn’t have the flexibility of what DS does (multiple pids, no
> necessary direct connection between pid and configuration annotation) but
> something with those properties wouldn’t be hard to design.
>
> Metatype is extremely useful and generating metatype from annotations is
> incredibly nice, but I would try to avoid requiring metatype for every
> configuration annotation.
>
> david jencks
>
> > On Oct 11, 2016, at 2:57 AM, Christian Schneider <
> chris@die-schneider.net> wrote:
> >
> > By default @Named("key") is used to inject a certain bean when type
> information alone is not unique. In blueprint-maven-plugin we map it to a
> bean id.
> > So simply using the key for configs might overlap too easy. So I am not
> sure which exact syntax we should use but the simple name is not enough.
> >
> > Support of different placeholders is also something that would be great
> to support. It is rather rare but people use it.
> > I think the must have is that we support placeholders from one config
> and the system properties or framework properties.
> >
> > Christian
> >
> > On 11.10.2016 11:22, Guillaume Nodet wrote:
> >> I like the use of annotations for config.
> >> I've implemented it for CDI and it's quite nice.
> >> I'm not sure that reusing @ObjectClassDefinition is a good idea, afaik
> SCR
> >> does not use it either.
> >> I'd rather create a new blueprint annotation for such support.
> >>
> >> Also, I'm a bit skeptic about @Named("${key}") and
> @Named("$system{key}")
> >> Why not using something simpler: @Named("key") and @Named("system:key")
> ?
> >> Or is that to support multiple placeholders with different syntaxes
> (${xx},
> >> $[yy]...) ?
> >>
> >>
> >>
> >> 2016-10-11 10:15 GMT+02:00 Christian Schneider <chris@die-schneider.net
> >:
> >>
> >>> 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 <http://www.liquid-reality.de/>
> >
> > Open Source Architect
> > http://www.talend.com <http://www.talend.com/>
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: [blueprint-maven-plugin] Ideas for config handling
Posted by David Jencks <da...@yahoo.com.INVALID>.
I don’t think i would consider ever recommending anyone use blueprint for anything, but if I were to design something like this I would take the opportunity to get one of the big advantages of DS also in blueprint, that all the configuration info is supplied in one event. So using your annotation example (which would not need the @ObjectClassDefinition for this use)
@Inject @Named(<pid>)
private ServerConfig serverConfig;
When a configuration with the appropriate pid shows up, a ServerConfig implementation returning the values from the configuration is created and injected. If the configuration is a factory configuration with the pid as the factory pid, then for each such configuration an instance is created.
This doesn’t have the flexibility of what DS does (multiple pids, no necessary direct connection between pid and configuration annotation) but something with those properties wouldn’t be hard to design.
Metatype is extremely useful and generating metatype from annotations is incredibly nice, but I would try to avoid requiring metatype for every configuration annotation.
david jencks
> On Oct 11, 2016, at 2:57 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> By default @Named("key") is used to inject a certain bean when type information alone is not unique. In blueprint-maven-plugin we map it to a bean id.
> So simply using the key for configs might overlap too easy. So I am not sure which exact syntax we should use but the simple name is not enough.
>
> Support of different placeholders is also something that would be great to support. It is rather rare but people use it.
> I think the must have is that we support placeholders from one config and the system properties or framework properties.
>
> Christian
>
> On 11.10.2016 11:22, Guillaume Nodet wrote:
>> I like the use of annotations for config.
>> I've implemented it for CDI and it's quite nice.
>> I'm not sure that reusing @ObjectClassDefinition is a good idea, afaik SCR
>> does not use it either.
>> I'd rather create a new blueprint annotation for such support.
>>
>> Also, I'm a bit skeptic about @Named("${key}") and @Named("$system{key}")
>> Why not using something simpler: @Named("key") and @Named("system:key") ?
>> Or is that to support multiple placeholders with different syntaxes (${xx},
>> $[yy]...) ?
>>
>>
>>
>> 2016-10-11 10:15 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
>>
>>> 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 <http://www.liquid-reality.de/>
>
> Open Source Architect
> http://www.talend.com <http://www.talend.com/>
Re: [blueprint-maven-plugin] Ideas for config handling
Posted by Christian Schneider <ch...@die-schneider.net>.
By default @Named("key") is used to inject a certain bean when type
information alone is not unique. In blueprint-maven-plugin we map it to
a bean id.
So simply using the key for configs might overlap too easy. So I am not
sure which exact syntax we should use but the simple name is not enough.
Support of different placeholders is also something that would be great
to support. It is rather rare but people use it.
I think the must have is that we support placeholders from one config
and the system properties or framework properties.
Christian
On 11.10.2016 11:22, Guillaume Nodet wrote:
> I like the use of annotations for config.
> I've implemented it for CDI and it's quite nice.
> I'm not sure that reusing @ObjectClassDefinition is a good idea, afaik SCR
> does not use it either.
> I'd rather create a new blueprint annotation for such support.
>
> Also, I'm a bit skeptic about @Named("${key}") and @Named("$system{key}")
> Why not using something simpler: @Named("key") and @Named("system:key") ?
> Or is that to support multiple placeholders with different syntaxes (${xx},
> $[yy]...) ?
>
>
>
> 2016-10-11 10:15 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
>
>> 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
Re: [blueprint-maven-plugin] Ideas for config handling
Posted by Guillaume Nodet <gn...@apache.org>.
I like the use of annotations for config.
I've implemented it for CDI and it's quite nice.
I'm not sure that reusing @ObjectClassDefinition is a good idea, afaik SCR
does not use it either.
I'd rather create a new blueprint annotation for such support.
Also, I'm a bit skeptic about @Named("${key}") and @Named("$system{key}")
Why not using something simpler: @Named("key") and @Named("system:key") ?
Or is that to support multiple placeholders with different syntaxes (${xx},
$[yy]...) ?
2016-10-11 10:15 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
> 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
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/